On Nov 16, 2007, at 2:57 AM, John C Klensin wrote:
I expected to dislike it because I consider "synchronize and run for
the airplane" and "synchronize before the stinking wireless link
goes down again and then actually read the mail offline" to be
_very_ important mail-use modes. I am also, to put it mildly
unwilling to lose multihop relaying to reach locations with less-
than-perfect or some-times-of-day-only connectivity. Consequently,
I see it as costly and burdensome on the receivers (and other "good
guys") while providing the bad guys only a temporary impediment.
John,
Sorry for the confusion in how the TBR Extension is intended to
operate. The TBR extension is to be used between well connected MTAs
and not at the MUAs. The end-user will not receive their email any
differently. You can still read your email at 30k feet. End-User
firewalls do not change. DDoS concerns related to the reach-back
mechanism would be at lower gains and easier to mitigate than would
direct threats from bots.
A Temp error is the _only_ means available to prioritize resources
when MTAs are overrun. The TBR extension provides an alternative for
completing an SMTP transaction, rather than the increasingly used "go
away for now" mode of operation. Using the TBR extension should allow
email to arrive with _less_ delay, and not more. This should involve
_fewer_ transactions and not more. Even if all connections used SSL
certificates, the need to protect resources would not change.
Receivers can still be inundated. Certificates can be purchased with
fraudulent credentials. Resources must still be protected where "go
away for now" makes the situation worse.
Message delivery would occur only after content had been retrieved.
Whenever a situation limits an ability to reach the origination, the
message can be carried in-band, but only after a delay when a Temp
error is needed. A greater portion of the effort to prioritize
resources must be placed upon the transmitter. The TBR extension
permits a graceful transition toward this strategy.
The reach-back mechanism can be any protocol. If imap, a proprietary
concern should be alleviated. SMTP is already being stressed, so it
really should be a different protocol or on a different port. These
details are really less important.
-Doug