ietf-mxcomp
[Top] [All Lists]

Re: Caller ID and ease of adoption (was Microsoft submitting Caller ID as draft RFC)

2004-04-12 16:25:37

Harry Katz wrote:
wayne [wayne(_at_)midwestcs(_dot_)com] wrote (in part):

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.

Yes, my experience agrees with this: The only use of Resent-* I've seen is an incorrect application by Mailshell.

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.

I doubt we really need to survey list operators. Instead, survey the software used.
This would include:    Sets Sender?    Sets MAIL FROM?
YahooGroups                 n               y
Mailman                     y               y
ezmlm                       n               y
Majordomo 1.x               y               y
Majordomo 2.x               y               y

Some of these may be dependent on site-specific configuration, or may have changed (hopefully for the better) since the messages I'm looking at were sent. If anyone can find this data for others, it could be useful.

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.  :-)

I, too, agree that RFC 2822 header validation is important from an end-user perspective, but I think there are major benefits to validating RFC 2821 data regardless of whether we go for the 2822 headers.

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.

If there is some way to hold the forwarding system accountable, and ensure that the end-recipient actually desires this forwarding, then it's fine to leave the MAIL FROM intact. However, in the modern email environment, there is no implcit trust between peer MTAs except by prior arrangement. Therefore, it think it makes much more sense to protect the common case of an MTA sending mail from an associated domain, and make those doing exceptional things, like forwarding messages, bear the labor of accepting accountability.

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.

I agree, every message posted to a list should have not only the List-* headers, none of which can be treated as anything but opaque data, but also a header known to contain an accountable domain.

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.

I believe that encapsulating the return path would be cheaper than adding a header, for a few reasons: 1. Computational cost - the forwarding service must ensure there is only 1 copy of that header present in the message. The cost of scanning the message headers before adding or replacing one is much higher than rewriting the return path unconditionally. The rewrite can be as computationally cheap as one can find or invent an algorithm to be, while the cost of scanning is potentially only bounded by inbound message size limits. 2. Implementation complexity - currently, no clear majority of MTAs implement any manipulation of RFC 2822 headers at all. While CallerID is primarily enforced by MUAs which are well equipped to handle the demands it presents, most MTAs or mailing list expanders would require some additional code to add and/or replace headers. On the other hand, mailing lists, for the most part, already implement MAIL FROM rewriting, and MTAs would only require minimal, small-scope changes.

Philip Miller

P.S.: Harry, please consider publishing CallerID as an Internet-Draft before it's submitted for RFC consideration. I think this simple opportunity for wider public comment could make for a much stronger proposal.