Dave Crocker <dcrocker(_at_)brandenburg(_dot_)com> wrote:
AD> I can think of a number of new protocols deployed at the edge, and
AD> in wide use, in significantly less than 3 years.
AD> Napster, for one: http://grammy.aol.com/features/0130_naptimeline.html
ok. central registration and a centralized query service. initially a
single implementation.
Yes. Edge deployments.
End-user work required to deal with RMX variants is similar. The
end users install new software (SUBMIT client) which connects to a
centralized service (ISP or business MTA). Everyone uses the same
client, but the "centralized service" is distributed, and everyone can
choose which service to point their client at.
You claimed that SPF imposes no user burden. The truth of that statement
does not hinge on whether other things impose a burden.
If I did, it was either a mis-statement, or an unclear phrasing on
my part. My messages should make it clear that I understand SPF may
require end-users to change their behaviour, or to upgrade software.
Characterizing adoption of an RMX scheme, versus giving up on email as
the only two choices is simply wrong. There are more choices than that.
Of course. But many people I know have simply stopped reading
"postmaster" mail for their domains, due to the number of bounces
(thousands an hour for a 10-user domain.) RMX/SPF would stop those
bounces *entirely*. Either the bounce would never be sent, or the
recipient could tell the bounce was about a fraudulent message, and
discard it.
Many MTA administrators I know like RMX, if only because it permits
them to read "postmaster" mail again. Lack of a useful "postmaster"
has significant cost and stability issues for many domains.
That is, a flaw in the design of SMTP is preventing another feature
of SMTP from being useful. The protocol design is contradictory, and
should be fixed. We should either not do bounce-path verification
(e.g. LMAP), and admit that bounces are no longer useful; OR we should
demand that bounces be useful, and resign ourselves to implementing
bounce-path verification.
[ 0/0 ]
Once again, a scheme that requires disabling the scheme, to support
significant, valid scenarios, is a very problematic scheme.
It's not "disabling" the scheme. It's working within the scheme to
acheive backwards compatibility with end-users who don't want to
change their behaviour.
And this is the entire reason for LMAP: to give recipients the
ability to tell valid from invalid scenarios. You can claim on a
mailing list that some scenario is "valid", but my MTA doesn't read
this list.
Alan DeKok.