News for hackers. Stuff that matters.
Re:Can I Email: ‘Can I Use’ for email by jlokier on Thursday September 12, 2019 @08:11AM (#20950511)
If the content isn't inline, perhaps it's better to have the mail server fetch it when the email is received, so that the sender can't track whether you are reading it.

This has been discussed before with regard to external links to images. I think that always made sense, but it makes even more sense to do this when the core content is external. Then fetching it would be just another part of the SMTP/HTTP transaction sequence to deliver a mail.

Re:Can I Email: ‘Can I Use’ for email by sjwright on Thursday September 12, 2019 @08:26AM (#20950618)
Exactly. If most mail clients downloaded it automatically upon receipt instead of on view then the tracking benefits get diluted to the point of uselessness.

(Actually, thinking further it would have to be done server side to avoid leaking your personal IP. For a webmail provider that’s obviously straightforward, while IMAP servers could be extended to automatically replace AMP email directives with a static HTML attachment.)

Re:Can I Email: ‘Can I Use’ for email by jcranmer on Thursday September 12, 2019 @09:34AM (#20951241)
So you want RFC 2017 basically?
Re:Can I Email: ‘Can I Use’ for email by sjwright on Friday September 13, 2019 @07:36AM (#20961144)
No, I want AMP email to never happen. Failing that, I want the email server to un-AMP-ify incoming emails for me.
Re:Can I Email: ‘Can I Use’ for email by rypskar on Friday September 13, 2019 @01:34AM (#20959459)
Should it do that for all emails sent to the domain, or only for valid addresses? If they only fetch for addresses in use this will open up for an easy way for spammers to verify if an address is in use or not
Re:Can I Email: ‘Can I Use’ for email by jlokier on Friday September 13, 2019 @09:12AM (#20961773)
Spammers can already verify if an address is _accepted_ because their message will be rejected with an error code at SMTP transmission time if it isn't.

The first stage of spam filtering, and greylisting, also reject at SMTP transmission time.

I'd do the HTTP fetch when SMTP is about to accept the message, making the HTTP round trip just another part of the transaction.

Since spam filtering is likely to look at the HTTP response, you might want to reject the SMTP transaction after seeing the HTTP response, rather than accept the SMTP transaction based on address alone.