In <9156B81DAA29204989AD43E88688FAAB01373D26(_at_)df-lassie(_dot_)dogfood>
"Harry Katz" <hkatz(_at_)exchange(_dot_)microsoft(_dot_)com> writes:
From: Matthew Elvey [mailto:matthew(_at_)elvey(_dot_)com]
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.
In fact, I'm not aware of a single client that displays Resent- today.
Well, I can name an MTA that displays at least the "Resent-From:"
header: Emacs-Gnus. (I've been using gnus since the mid 90s.)
I'm actually very surprised by this, I didn't think gnus displayed the
Resent-From: header.
However, as Phillip Hallam-Baker says, we need to look at the clients
that the billion plus real users of the Internet use, not the ones
used by the handful of geeks who attend IETF.
As I've noted elsewhere, we believe that this value will eventually need
to be shown to end users if that's the domain that's validated.
Well, this gets back to the "user experience" thing. I am not very
comfortable with the idea that vast majority of users will not see the
validated header until they upgrade their MUA. This leads me back to
saying that if we are going to validate the RFC2822 data, we need to
validate the From: header, not the Resent-* headers, and probably not
the Sender: header.
Yeah, I know, (recent?) versions of Outlook display the Sender:
information. Does anyone know the percentage of user use an MUA that
displays the Sender: header?
The reason we have the Resent- headers to our list (even though they're
not visible today) is for ease of adoption. We think it'll be easier
for forwarders to just insert this header than to adopt SRS or VERP and
then start handling the bounces coming back.
Well, "ease of adoption" is one reason why I think that there
shouldn't be a requirement of adding new headers.
* There are far more mailing lists that would need to be upgraded than
email forwarders. Any proposal that requires mailing lists to
change is not going to be easily adopted.
* For mail forwarders, either SRS (or similar) or adding headers
requires a change to their MTA. Right now, I know of more MTA
support for using SRS than for adding headers. I suspect that in
both cases, either of these approaches could eventually become
equally easy to do.
* For mail forwarders, even if SPF wasn't being widely deployed, there
is already a reasonably large (and growing) number of mail admins
that are doing RFC2821 validation in an ad-hoc manner.
I know ... I'm repeating myself.
Yeah, and so am I. :-<
The directOnly attribute lets sending domains to declare that they don't
*knowingly* send mail via mailing lists [or mail forwarder].
While I think it pretty safe for folks like paypal to assume that the
mail they send rarely gets sent directly to mailing lists, I think a
non-trivial amount gets sent to email forwarders.
Again, from what I understand of the C-ID proposal, it can't
distinguish between an email forwarder and a mailing list. They are
both required to insert one of the same set of headers.
On the receiving side, then, an additional check is prescribed whenever
there's a difference between the purported responsible domain of the
message and the RFC2822 From domain. If the directOnly attribute is
found, further action can be taken. We have not specified what action
should be taken other than to suggest "significantly perjorative
penalties." We think this should be a local implementation decision
because a certain amount of judgement needs to be exercised here. For
example, others on this list have noted that users typically know what
lists they're subscribed to and what forwarding addresses they've set
up. If a user has placed those forwarded email addresses on a safe list
then the message may be deemed legitimate even though there's a
discrepancy between the purported responsible domain and the RFC2822
from domain.
Ok, if I understand what you are saying here, C-ID doesn't do a really
good job of protecting a domain against phishing unless they use the
directOnly attribute. In which case, C-ID doesn't say how to handle
this situation, so it alone doesn't really do a good job against
phishing. :-<
I think it is *very* important that the RFC2822 From: header gets
validated somehow. It is the only header universally displayed in the
vast majority of MUAs. It needs to be validated even if it passes
through mailing lists or email forwarders. The validation can not
allow people to substitute the body of the email with spam.
I guess this leads me back to the question: Why not S/MIME with a
flag in the DNS somewhere that says "this domain always uses S/MIME"?
(Or GPG, or something similar.)
-wayne