-----Original Message-----
From: owner-ietf-mxcomp(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-mxcomp(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of wayne
Sent: Monday, April 12, 2004 8:22 PM
To: IETF MXCOMP
Subject: Re: Caller ID and ease of adoption
In
<9156B81DAA29204989AD43E88688FAAB01373C1C(_at_)df-lassie(_dot_)dogfood>
"Harry Katz" <hkatz(_at_)exchange(_dot_)microsoft(_dot_)com> writes:
wayne [wayne(_at_)midwestcs(_dot_)com] wrote (in part):
For mailing lists, handling bounces is already a requirement.
For mail forwarders and greeting-card sites, most LMAP
proposals do
require a burden to handle bounces. On the other hand,
this reduces
the burden on other sites that have to handle bogus bounces.
We took the view that it would be easier for forwarding services to
adopt to one of these proposals if they didn't have to absorb the
additional cost of handling the bounces and simply inserted another
header. It would also eliminate the need for them to
encapsulate the
RFC2821 MAIL FROM using SRS or VERP on every outgoing message, and
unencapsulate on any bounces that came back.
I'm sure that most mail forwarders do not want to have to do
SRS (or the like) and that adding headers would probably be
easier for them.
On the other hand, there is a reasonable large, and growing
number, of mail admins that are already blocking email based
on the MAIL FROM and the IP address. That is, these mail
admins are doing LMAP-like checks without using any of the
LMAP proposals.
These checks are often very ad-hoc, not complete and often
not accurate. These mail admins are creating the LMAP-type
systems because blocking all email that claims to come from
the major free email providers but coming from other IP
addresses blocks a lot of spam. Things like SPF greatly
accelerate this trend, and eliminates many of the
inconsistencies that the ad-hoc methods create, but if you
are serious about reliably forwarding email, you are going to
have to do something like SRS anyway.
Meng, being a professional email forwarder by trade, can
easily provide (often humorous) examples of these ad-hoc systems.
While this doesn't reduce the pain of adoption for email
forwarders, it does make the RFC2821 proposals more likely to
be supported.
The problem, as I've noted elsewhere is that over time MUAs will need to
display the verified address to the user if that address is different
from the RFC2822 From. Otherwise we'll leave users with the false
impression that the From itself has been validated. Whether it's the
MUA software that does this, or whether the MTA modifies the display
portion of the From, or some other method, is a side issue.
The point is that if you verify the bounce address, that does mean SRS
or something like it will need to be adopted by forwarders.
SRS creates addresses that are not intelligible to humans.
We must not adopt a solution that presents unintelligible information to
end recipients.
-wayne