Douglas Otis wrote: > On Nov 15, 2007, at 11:20 AM, David F. Skoll wrote: >> You still haven't explained this: What's in it for the sender?
> Imagine the outbound server is that of a bulk emailer or that of a large > ISP. Our company issues realtime temp error blocks resulting from > ongoing spam runs emerging from a server. These blocks protect > resources needed to content filter incoming email and prevent an > otherwise global denial of service. Currently, the affected server will > receive a Temp 451 error and needs to retry the message at a later point > in time. To discourage rapid retries, dispositions will not change in > less than an hour. Right. So anyone who runs a large e-mail setup knows that you shuffle tempfailed mail off to a fallback MX host. Your primary hosts' queues stay nice and small and the fallback MX host can be optimized for deep queues. > By providing the TBR Extension, the outbound serve is able to complete > their transaction using the TBR verb now rather than the DATA verb at > some point later. This eliminates any need to retry. But it still means the sender has to hang on to the message. And worse, it cannot possibly know when its safe to relinquish it because mailing-list exploders can cause the number of required fetches to be indeterminate. >> Why would an e-mail sender be interested in deferring the receiving >> SMTP server's obligation to deliver? As an e-mail sender, I want the >> e-mail out of my hair as soon as possible! I don't want to have to >> hang on to it! > Understandable. The current levels of spam, which in some cases is > exceeding 99%, simply overwhelms any ability to filter all messages. Do you have evidence to support that? > Content filtering alone can not keep up, Do you have evidence to support that? > Content filtering is also, in the long run, the wrong approach. That's your opinion, not a fact. I happen to believe the opposite: Content-filtering is the only long-run viable approach because in the end, the spammer can fake everything but he/she still has to get the sales pitch across. > A bad actor is always able to find new ways to obfuscate their > message. A bad actor won't use TBR. And a bad actor will subvert TBR, including abusing it to *create* denial-of-service attacks as I illustrated in another message. [...] > Whether you are holding the message in an outbound queue, or make it > reachable through a reference, servers being flagged as currently > sending spam will need to hold the message. Nothing is able to scale in > a manner that could allow an unlimited amount of abuse. The TBR > extension provides an effective alternative that should make life easier > for both the transmitter and the receiver. I don't see how it makes it easier for the transmitter. > The TBR extension provides the sender an alternative to continuously > retrying to send the same message. The TBR extension allows these > otherwise blocked senders a means to complete the SMTP portion of the > exchange. How many senders currently see this as a problem in need of addressing? A good greylisting implementation will have a fairly small impact on valid senders. Regards, David.
