Splitting out another separate topic.
wayne [wayne(_at_)midwestcs(_dot_)com] wrote (in part):
-----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: Sunday, April 11, 2004 6:35 AM
To: IETF MXCOMP
Subject: Re: Microsoft submitting Caller ID as draft RFC
4. Ease of adoption: We believe our proposal will be much
easier for
a broader range of senders to adopt, including list servers,
electronic greeting and invitation services, and mail
forwarding services.
I could be wrong, but I think there are far more mailing
lists servers out there than mail forwarders (excluding
purely internal forwarders). I think there are far more mail
forwarders than greeting-card type services. So, if a
proposal breaks every single greet-card site, while breaking
only a very tiny faction of the existing mailing lists, it
will be better than a proposal that breaks even a small (but
not tiny) number of mailing lists.
RFC2821 already says that mailing lists MUST use the list
admin for the MAIL FROM. In practice, it appears that most
mailing lists do this. Hence, RFC2821 checks will likely not
effect very many mailing lists.
It is not so clear to me whether large numbers of mailing
lists would not changing in order to comply with C-ID. If I
understand the C-ID spec correctly, the "responsible domain"
is found by checking the following headers, in this order:
Resent-Sender:, Resent-From:, Sender:, and From:.
I did a *very* quick survey of the ~30-35 mailing lists I'm on.
*None* of them use the Resent-* headers, which the C-ID spec
says that they SHOULD use. Many do not set the Sender field
(e.g. Yahoo Groups, bugtraq, etc.) and others appear to set
the Sender: to the person who sent the email to the list
(e.g. the debian lists).
You're right, virtually no one is using Resent-* headers today. On the
other hand, in my experience Sender is quite widely used. This mailing
list is a good example. Messages from this list appear to me in Outlook
as "From IETF MXCOMP on behalf of Wayne" for example.
So, this very limited amount of data on RFC2822 headers seems
to show that either many mailing lists will have to change,
or RFC2822 checking can not depend on much other than the
From: header.
I guess we need to survey some of the list service operators to find out
definitively how many are using sender today. My understaning is that
in fact most of them would be compliant with Caller ID today.
Again, I want to be clear that I *REALLY* want to see
validation of the RFC2822 data. I think it is *VERY*
important. I just do not think I understand the situation
well enough to be comfortable any of the proposals, hence my
support of doing RFC2821 data first.
Well, I'm glad we agree on the importance, at least. :-)
Many
of these services today do not use their own domain names
in the 2821
MAIL FROM because they do not want to handle bounce messages.
These services can do many things, but they should not be
allowed to set the RFC2821 MAIL FROM to a domain name that
they do not own/control and force others to handle the bounce
message instead.
Agreed. However in the case of forwarding services it's not really a
matter of *setting* the RFC2821 MAIL FROM to a domain name they don't
control. Rather they're just forwarding verbatim the message they
received from the origination domain.
In order to
comply with Caller ID all they need to do is ensure that at
least one
of the body headers we check has their domain name on it.
I may well be confused here, but doesn't the C-ID spec
require that the highest priority header have their domain
name rather than at least one of the headers?
Correct. I should have been clearer. In the case of forwarding
services, inserting a Resent-From header is likely the most appropriate
thing to do. List services that are not already inserting a Sender
header could insert one (if one is not already present) or insert a
Resent-From header.
Under SPF,
these services will have to modify the 2821 MAIL FROM
according to the
Sender Rewriting Scheme (SRS) or VERP, plus handle any
bounce messages
that come back. We believe this is a more extensive change
and could
place a heavier workload on these services. To put it another way,
SPF really means adopting TWO new standards. Caller ID has
no such requirement.
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.
Thanks,
Harry