[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


Harry Katz wrote:

Philip Miller wrote:
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.

If it's of interest, imc.org and IETF both run Majordomo. SourceForge.net, which hosts some of the highest levels of list activity on the Internet, runs Mailman, IIRC.
I recall Microsoft running some mailing-list service at some point. Is tha still around? If so, how does it fit in above?

At any rate, the real thing to note in that is that MAIL FROM is already handled in the vast majority of mailing list cases, while Sender is not always, and Resent-* is never used.

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 adopted more
quickly.

I would have disagreed here, but as you later point out, I had misread the specification of the Resent headers. I didn't realize that they were added as trace fields. In that case, adding Resent headers should be low-cost functionality.

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.

Sorry, I misread the section of 2821 that describes Resent headers. I completely missed that they are added as trace fields at the top of the message. I can see some little complexities implementing this in some MTAs, but in the general case, this wouldn't be too bad.

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.

Yes, you're correct.

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 is at the MTA.
That's our intent.

OK, I was unaware of that. However, enforcement at the MTA will then bring the costs of header parsing to the MTA.

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.

Perhaps we should be working to make this partition more effective. Considering that the design of 282[12] are such that either one can work decently without the other, we should be careful of such statements.

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.

Great.

Philip Miller