John Leslie wrote:
Dave Crocker <dhc(_at_)dcrocker(_dot_)net> wrote:
John Leslie wrote:
The "fix" Doug and I put into TBR is to extend the time to formal
handoff, by any amount the receiving mail system may choose, which
accomplishes much of what keeping the TCP connection open would -- at
a far smaller cost (the queue of URIs could be written to disk, for
one example).
Although only a near-term, tactical benefit, greylisting directly
impacts mail from bad actors.
I wouldn't describe it as "only near-term". I don't notice folks
abandoning graylisting in droves. When graylisting is used to buy time
to gather enough reputation information, its long-term benefit can be
substantial.
Try ignoring my reference to 'near-term' here.
My intended focus was on the direct impact on bad actors. That's what needs
the attention.
Its serious downside is that it also impacts first-time mail from good
actors.
First-time email from originators who haven't yet developed a
reputation, alas, _deserves_ to be delayed.
Nicely cavalier.
In contrast, your scheme will only be used for mail from good actors.
That's not as certain as you think. Many spammers seem to choose
their customers for stupidity, and such customers might well believe
In the presence of meaningful reputation services, please provide some
empirical support for the claim that bad actors use those services.
that the spammer has delivered on their promise merely by delivering
the TBR. In any case, we cannot _assume_ only good actors will use
TBR.
Turns out we can, for the reasons others have cited.
This is exactly the mail that does *not* need to be held up.
...
The mail which "does not need to be held up" is mail from well-known
and trusted senders. Anything else may well be abusive in someone's
eyes. Hopefully, graylisting won't be applied to the first kind.
Did you by any chance notice that you did not refute the concern I raised?
So the mechanism increases delay
Measurably, probably; perceptibly, probably not.
Again, absent empirical data, that's a dangerous assumption.
and at least doubles the transaction load for mail from good actors,
I continue to ask you for the basis of this calculation. I'm _not_
going to guess what you mean by this, Dave!
I explained it in a private note. Now publicly:
SMTP is a single session that delivers a message. That's a "transaction".
Within SMTP are protocol exchanges. They also constitute transactions, but at
a different level.
The proposed scheme requires a minimum of two sessions, thereby at least
doubling the higher-level transaction cost. Since the proposal seems to
retain the same number of within-SMTP protocol exchanges (swapping DATA for
the URL citation), there's no saving at the micro-level, but there is the
addition of whatever protocol exchanges are needed for the follow-on fetching.
I gather that is, at the least, and HTTP connection and FETCH.
Protocol exchanges and sessions create their own costs, in packet switching
worlds, separate from raw bandwidth requirements. They draw from a different
performance budget and often are the higher cost. At a minimum, think of a
satellite channel. Might have very high bandwidth, but delay always sucks.
Transaction overhead is like the cost of that satellite delay. Separate from
bandwidth.
ESMTP added options in a way that careful avoided adding even one protocol
exchange round-trip. That's how important this issue was considered amongst
the email protocol community.
By contrast, the current proposal adds 100% or more round-trips with no
certainty of massive benefit. And I suggest that anything this expense pretty
much needs a certified guarantee of massive benefit.
With the spam load generally acknowledged to be 90% or more, it
would be a major victory to _have_ a mechanism used only by good
actors.
If you are looking to created a trusted infrastructure, there are more
efficient ways to do it.
For example, define SMTP over a new port, with required authentication by
client SMTP sites, and whatever other trust-related capabilities are deemed
appropriate. Servers that support the new port publish an MX-like record.
That that approach that will require some sort of client certification is
pretty much the same problem we are already tackling, albeit with a different
twist.
Where is the benefit, here?
There isn't only one benefit. Greylisting without encouraging a
doubling of SMTP traffic would be a benefit.
Greylisting doubles SMTP traffic for first-timers.
Your scheme at least doubles total transaction traffic for all good-guys,
forever.
Smoothing network load
by scheduling TBR retrievals would be another.
Traffic management by imposing arbitrary overhead is not generally held in
high regard.
There's the benefit
of having a mechanism available to those who must work from Cable
Internet addresses which are increasingly blacklisted. And please
don't forget the benefit of transferring an immutable message text.
This suggests that you are trying to fix IP Address-based trust, just as the
industry is attempting to move to Domain Name-based trust.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net