On Mon, 12 Apr 2004 13:28:34 -0700, "Harry Katz"
<hkatz(_at_)exchange(_dot_)microsoft(_dot_)com> said:
wayne [wayne(_at_)midwestcs(_dot_)com] wrote (in part):
... 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:.
C-ID has no advantage over 2821-only checking if this is the
case, because phishers will quickly adapt and send spam like:
Resent-Sender: foo(_at_)spammerWithValidC-ID(_dot_)dom
From: service(_at_)paypal(_dot_)com
and the first header won't be visible in most clients, right?
Harry, you said we need to check against what the user will see.
Clients generally don't display "Resent-Sender:", yet C-ID allows it?
Doesn't make sense to me.
Whaddya think of my fledgling idea for a solution to this problem
("Strong From: check seems possible")?
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.
If C-ID's support for 'Sender:' is a defect, it's not relevant how widely
supported it is.
(Requring ezmlm's entire installed base, plus mailing lists on sendmail
and exim to migrate/upgrade is another nail on the coffin, however!)
PM said:
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.
Section 10 issues Microsoft needs to overcome, yes? IIRC, Microsoft's
demands with respect to C-ID-related Intellectual Property are
inconsistent. Seems to me that it hasn't been published primarily
because this IP is not yet disclosed and not yet obtainable "under openly
specified, reasonable, non-discriminatory terms."
Re. naming collisions: IANA should of course be used to avoid this in
LMAP/MARID extensions.