Douglas Otis wrote: > When the SMTP client's reputation is unknown, an SMTP server is unlikely > to Perm Error at the EHLO. Temp Errors at this point might be used to > discern whether the SMTP client keeps state, as with greylisting. Temp > errors might also be used to delay acceptance when a spam campaign is > detected as being active at an SMTP client handling messages from both > good and bad actors. TBR provides a safe alternative to greylisting and > temporary holds.
How is it "safer" than greylisting? [...] > This critique does not apply for a few reasons. The sender is unable to > lie about the message source, and determining the source will not cost > the recipient additional resources. How does not being able to lie about the message source help reduce spam? Remember, go back to the threat model: Serious spammers have essentially unlimited bandwidth and unlimited CPU power. When you control an army of tens of thousands of bots, it's cheap enough to set up a few hundred HTTP servers to serve your TBR messages. (That's assuming spammers even go to the bother of using TBR.) > Accepting and then processing a 512 byte message results in fewer > packet exchanges than would refusing 2 or more multi-KB messages. > (At today's level of spam, this could be estimated +20 at +8 KB.) Is there evidence that the number of bytes or packages involved in e-mail transfer is a problem? I would guess that ISPs have far more of their bandwidth chewed up by P2P and HTTP/HTTPS traffic than e-mail. IOW, I don't think the problem that you are trying to solve is worth solving, and I don't think the real spam problem is solved by TBR. Regards, David.
