3 ms·

I interpret the article you linked that a abuse mail would be sent, quote: "from users to some anti-spam center". While I propose that the mail transfer agent (

by z3t4 8y ago

I interpret the article you linked that a abuse mail would be sent, quote: "from users to some anti-spam center". While I propose that the mail transfer agent (MTA) on the receiving end tells the sending MTA whether or not an e-mail was (automatically) flagged as spam. Sending MTA: HELO I would like to send an e-mail Receiving MTA: Great, send it to me Sending MTA: Sending ... Receiving MTA: Analyzing mail, please wait ... Receiving MTA: Email accepted, but it was marked as spam Sending MTA: OK, goodbye It would then be up to the sending MTA to notify the user, like it does now when an e-mail is undelivered.

detaro 8y ago
there's an "e.g." in front of the quote, and the example shown is for reporting to the source domain, which then can decide how to handle it (e.g. inform the user if it was a false positive, or take measures against the user if it was actual spam)
wahern 8y ago
The fundamental problem is that SMTP mandates accepting multiple recipients per transaction, but only a single status code when completing the transaction. Transaction level rejection is incompatible with per-user rules that filter the message body. Ideally what's needed is a mandatory, pervasively supported SMTP extension that permits per-recipient status codes, such as LMTP provides. More feasible is permitting MTAs to accept only a single recipient per transaction, but even that is difficult given the huge installed base of MTAs and libraries.