3 ms·

Spammers use different (hacked) servers, so by the time someone have acted on the abuse letter and blocked outgoing SMTP the spammer has switched servers 10 tim

by z3t4 8y ago

Spammers use different (hacked) servers, so by the time someone have acted on the abuse letter and blocked outgoing SMTP the spammer has switched servers 10 times. About the spammer iterating until the message get through it probably wouln't be worth the time, or the spammer doesn't have the technical ability to, or he/she would be able to get a real job that pays out 1000x more then what those spams generate. Getting a spam notification would also make lazy major e-mail providers to use existing standards such as SPF because their customers would complain.

detaro 8y ago
I'm not sure what this response has to do with me telling you about an existing standard for what you propose?
- 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.
autoexec 8y ago
Spammers do tend to use botnets these days but ISPs would love it if you sent reports to their abuse teams. Each ISP can help clean up bots on their network and while it is basically an endless game of whac-a-mole it does have an impact on the spam volumes leaving respectable networks. If you can automate the process of sending off a notice to the abuse team in addition to any other filter/drops it would be a win/win for everyone. ARF is great, but as long the message includes the full message headers it should be possible for the ISP to track down the infected user responsible.
deleted 8y ago
[deleted]

by z3t4 8y ago

detaro 8y ago

I'm not sure what this response has to do with me telling you about an existing standard for what you propose?

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.

autoexec 8y ago

Spammers do tend to use botnets these days but ISPs would love it if you sent reports to their abuse teams. Each ISP can help clean up bots on their network and while it is basically an endless game of whac-a-mole it does have an impact on the spam volumes leaving respectable networks. If you can automate the process of sending off a notice to the abuse team in addition to any other filter/drops it would be a win/win for everyone. ARF is great, but as long the message includes the full message headers it should be possible for the ISP to track down the infected user responsible.

deleted 8y ago

[deleted]