John Leslie wrote:
2. At best, this reduces total bytes over the [SMTP connection?]
Actually, our concern was bytes an SMTP server is responsible for
buffering: this may not be much of a problem for many folks (yet),
In most Internet situations, transaction costs outweigh bandwidth costs. Your
scheme doubles the former, at a minimum, while introducing further delay and
synchronization constraints.
To repeat: while smtp-time evaluation does show up as a concern among some
anti-abuse operations folks, it has never been seen as a serious priority by
the general community.
With abuse email at 90+ percent of the total traffic, I think we'd have seen
the 'scaling' problem by now, if we were going to. Yes, it can (and will) get
worse, but ultimately this needs a deeper solution, which I believe source
authentication serves better.
but the requirement for a notification message does not reduce the
number of network 'transactions' -- in fact it increases them by
100% or more.
I'm not clear what "requirement" you're referring to.
There is no notification message required in this SMTP extension:
in fact there is a prohibition of sending DSNs before the reverse
path is verified. The notification of acceptance of responsibility
for the TBR _is_ fetching the reference: none of the errors mentioned
are required to be sent unless the originator is considered worthy.
3. This presumes that making a real-time decision is a current problem,
when it is not generally held to be a major factor among the anti-abuse
community.
Your "community" may not be the same as mine. I take the very
existence of graylisting as proof that real-time decisions are often
impractical.
Graylisting is generally acknowledged to have current tactical utility but
something that spammers will adapt to whenever they feel the need. So it's
not a long-term (strategic) tool. The cost of a standard requires that it
provide stable, long-term benefit.
4. It presumes that users can make the right decision.
Actually, the TBR extension protocol leaves _no_ decisions to the
user (unless you read the part about
Yeah, I missed that it's only goal was to defer the DATA portion for awhile.
In effect, altering the timeout for the DATA portion.
So that just leaves the matter of realistic long-term efficacy.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net