ietf-mxcomp
[Top] [All Lists]

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

2004-04-12 17:29:23



-----Original Message-----
From: Philip Miller [mailto:millenix(_at_)zemos(_dot_)net] 
Sent: Monday, April 12, 2004 4:26 PM
To: Harry Katz
Cc: IETF MXCOMP
Subject: Re: Caller ID and ease of adoption (was Microsoft 
submitting Caller ID as draft RFC)

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


Interesting data, thanks.  I still think it's relevent to ask how many
lists out there are operated by each class of server, in other words,
how many actually have to change.  I would guess that Majordomo accounts
for a huge chunk for example.

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.

We certainly have no objection to any forwarding service that does put
its own domain on the RFC2821 MAIL FROM and begins to handle the bounce
messages.  What we're trying to achieve though is rapid adoption and in
our view inserting a Resent- header is more likely to be adopeted more
quickly.


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.

Sorry, I have to disagree here.  Inserting a Resent- header is no more
complex than inserting a Received header and is intended to be done in
the same place.  You can have multiple Resent- headers exactly as you
can Received headers.  Each MTA along the delivery path could insert
it's own.  Yes, if you're inserting a Sender header you're supposed to
look for a previous one, but that doesn't apply to Resent- headers.  

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.

As I noted above, there's no "manipulation" involved.  You just write a
header.  

Also, it's not true to say that "Caller ID is primarily enforced by
MUAs."  We certainly believe this will happen in some cases.  But the
best and most efficient place to enforce Caller ID as at the MTA.
That's our intent.  

At a more general level, I do not think it is possible to partition this
problem along the lines of "MTAs look at RFC2821 data, and MUAs look at
RFC2822 data."  That might be a tempting approach but owing to the
inter-relatedness of this data, and to the desire to block as much spam
as possible at the network perimeter, such partitioning won't be
effective.  


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.

That's our intent and we're working on it.