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.