But when I'm able to script (i.e. when I'm fully awake), it's in my best interests that I don't write that script, so I don't. And if I'm able to write that script in my sleep ... well, I've lost then (but also, in a way, won!) :P
I thought push is a standardized imap extension and any capable client can use it, if the server is configured properly. Does push on iOS require apple to somehow allow you to use it with your provider, or why is it such a big deal?
IMAP "push" usually means the IDLE extension, where a client holds a connection open and waits for the server to report that something has happened. This works ok, but isn't great on mobile because holding a TCP connection open is usually difficult on flaky networks and consumes battery.
iOS Mail doesn't implement it, instead doing a poll every 15 minutes. However it also implements a separate push system which allows true push if the server supports it. The details on how to support this aren't public information.
We talked to Apple, and they were kind enough to give us access to this system. We implemented it on our side, and now when an email arrives at FastMail we can immediately signal to Mail.app that there's new mail available.
> IMAP "push" usually means the IDLE extension [...]
> iOS Mail doesn't implement it, instead doing a poll every 15 minutes. However it also implements a separate push system which allows true push if the server supports it. The details on how to support this aren't public information.
"The details on how to support this aren't public information." My biggest computer-related fears summarized in a single sentence.
From skimming the notes it looks like it's essentially a way to send APNS notifications to Mail.app and requires a cert from Apple. You could run it from your VPS once you get the cert.
I guess that this is achieved using a server-side communication: the Fastmail server send the notification to the Apple servers and the Apple server sends the notification to the user's device. So wireshark probably won't help.
Sounds like it uses APNS, rather than IMAP push. For the latter, you need a daemon listening, which you can't do on iOS. Plenty of Android apps have IMAP push, for example.
The article says "We’ve enabled Push IMAP" and their instructions tell you how to setup imap email account.
But yes, using APNS for notifications probably makes sense (bandwidth, less connections, battery, ...).
This is really annoying. What I find more annoying is response like "We will process your request within 30 business days." (and after that period receive another spam). What could possibly take 30 business days to unsubscribe email? This is evil.
I would also like to see some sort of standard - like email header with link, that would unsubscribe you. Outlook/thunderbird/etc could just show button (probably next to "mark as spam" :)) and you couldjust click and be done. I think google tried something like this, but I've never heard of anyone else.
> What could possibly take 30 business days to unsubscribe email? This is evil.
Companies can, and do, take out lists of subscribers and pass them to agencies to run campaigns for them, with potentially long lead times. Still stupid, but that's usually the reason.
Regarding standard, the List-Unsubscribe: header is sort-of that. It's not used much because there's little reason to - most clients don't do anything with them.
Gmail does use List-Unsubscribe: when you mark as spam a mail which has a valid List-Unsubscribe header, it will ask you if you want to unsubscribe instead, and will handle the unsubscribe request automatically.
The typical reason is that there's a whole host of systems that might be sending e-mail on behalf of the company, so there might be some delay (generally far less than 30 days) for it to flow through whatever integrations are set up, and hey - since there's going to be a delay anyway, why potentially shoot yourself in the foot by giving yourself less than what you're entitled to by law?
That's possible. But if DNS changes can propagate throughout the entire world in 24 hours, seems like removing my email from a bunch of Internet databases could too.
I'm assuming that the thought process businesses are going through goes something like:
- We have a complex series of integrations (marketing automation -> CRM system -> app -> transactional e-mail provider) (as one example) where propagation isn't real time and could take a few days (if say, each of these were propagated on a nightly batch).
- Something could go wrong with any of these.
- It's better to err on the side of caution and give a super-conservative estimate and always beat it by a huge margin, than give an accurate estimate and occasionally break it (particularly with something as sensitive as unsubscribes).
Sounds like a misinterpretation of CAN-SPAM which says:
"Any opt-out mechanism you offer must be able to process opt-out requests for at least 30 days after you send your message. You must honor a recipient’s opt-out request within 10 business days."
which means the recipient gets 30 days (from receipt of each email) to opt out, the sender has 10 days to process the opt-out.
Yeah, storage is cheap, let's go wild and add some features that might be useful for a handful of people. Reminds of time when excel had simple flight simulator in it...
Nothing new, really. Methods and tools can help you, but do not guarantee success. Saying that some project failed because they used/didn't use something dosn't make sense to me. In the end, it's all about developers and overall project management.
Sorry, but this is IMHO useless. It doesn't work in all browsers (and causes errors/warnings in those unsopported), requires extra javascript and adds no real value. It just crams console with irrelevant data. There are better ways for this - humans.txt or html meta tags.
No. This does not affect their ability to use it. This certificate is simply no longer trusted by other parties (rightfully, because it was compromised).
As matter of fact, this may not even be his doing.
What if the 3rd party the FBI wanted to intercept via this Cert has now been 1) notified that there is a problem and 2) can no longer be intercepted (unless their browser does no CRL or OCSP checks on the domain's cert)?
No, that's not the point I was trying to make. The people in Washington D.C. that sit in fancy leather chairs have repeatedly demonstrated their lack of critical thinking skills, so I use terribly bad sarcasm to illustrate what their puny brains will think of next.
Interesting point. AFAIK they requested the key to decrypt previous communications. From security point of view, his move makes perfect sense. If FBI wanted to decrypt future communications, they would probably have specified that in their request. Then he would indeed break court order and could be hold responsible.
On the other hand, it would be hard to prove any actual obstruction, since the service was shut down and all users notified about this whole situation.
So, he's not 'mindless flocking sheep' because he wants new device from apple. He wants it because it's fashionable. I can't help it, but it sounds like 'mindless flocking sheep' to me, too.
