Hacker News Reader

Comment by Animats | Hacker News Reader

The usual checklist for anti-spam ideas applies.[1]

Some minor fixes to implementations might help, though.

- Mail forwarders and the SMTP server side of receiving servers should, when possible, forward immediately, making a connection to the next node while holding the incoming SMTP connection open. Pass back errors immediately as SMTP errors if at all possible. Phone to phone emails should be as fast as SMS.

- Same for spam filtering. Reject at the SMTP level for invalid sender identification. Gradually tighten up on invalid sender identification. In general, reject and pass back errors to the sender rather than sending to a "junk" folder. This is useful for making the big services clean up their act. If Google's gmail sender gets a hard reject at the SMTP level for a lot of mails from a sender, they will probably do something to the sender.

[1] https://trog.qgl.org/20081217/the-why-your-anti-spam-idea-wo...

View on HN

> Same for spam filtering. Reject at the SMTP level for invalid sender identification.

This is what Posteo (posteo.de) does by default* instead of accepting emails and putting them in a Spam folder. [1] It checks for a few different things and rejects the mail if the spam criteria are met. In my limited experience, many mail server admins of large organizations don’t even look at these email rejections to take any action. The result is that the mails keep getting rejected and the receiver doesn’t even know the context or content (by design).

* Posteo now has the option of accepting mail and putting it in the Spam folder too, if one desires this mode of operation.

[1]: https://posteo.de/en/help/how-does-the-posteo-spam-filter-wo...

Nice. That, plus the first item I mentioned, real-time forwarding, would mean that fails would show up immediately in your sending program, rather than a possible bounce message from a forwarder. Anything that can reject mail should work that way. The recipient's final IMAP server, which may have spam filtering, should also pass back rejections as SMTP statuses. So, if you get the "send completed" from your sending SMTP client, that should mean it's in the recipient's mailbox waiting to be read. This would improve the user experience for person-to-person email.

This is completely backwards compatible, so it's quite do-able as an enhancement. Most email forwarders today are old and from the store-and-forward era, and from systems where opening large numbers of TCP connections was a problem.

There's a sub-status for rejected spam:

    550 5.7.1 Delivery not authorized, message refused

That subcode list hasn't been changed since 2003. A few new codes would be useful. I'd suggest:

    550 5.7.8 Message refused - spam
    550 5.7.9 Message refused - not compliant with laws in recipient's region. (CAN-SPAM, etc.)
    550 5.7.10 Message refused - phishing attempt / hostile code
    550 5.7.11 Message refused - previous messages from same sender also refused

Let the spam filters talk back that way to the delivery services. It would be useful if mail delivery services noted such statuses and gave the sender a spam strike. They don't have to pay attention to that info, but the better ones would.

> many mail server admins of large organizations don’t even look at these email rejections to take any action

Because, sadly, it's trivial to forge the return address and generate (many!) rejections to places that didn't send the email in the first place.

(I've only got a tiny email server and I largely stopped caring about bounce messages a decade ago for this very reason. I can't imagine the volume Gmail or Hotmail get.)

e.g. https://www.altospam.com/en/news/bounce-the-mail-bounce-atta...

That's another advantage of making live connections when forwarding. The errors always go back to the real sender.

Reply on news.ycombinator.com