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.