[Mailman-Users] Yahoo Groups' From munging and X-Original-From

[Mark Rousell]

On 25/05/2014 18:48, Richard Damon wrote:
> On 5/25/14, 11:48 AM, Mark Rousell wrote:
> My view is that any attempt to have the Mail User Agent show a message
> that went through a mailing list as if it originated from the original
> poster (and only from that poster) is doomed, because the whole point of
> DMARC, is that domains that that are using DMARC are indicating that
> email that appears to be from their domain is only supposed to get to
> you from that domain, and others aren't supposed to be able to
> masquerade as it.

Three initial responses to this occur to me:

(1) Who says that DMARC will be successful? (Note that I am not opposed
to DMARC or its intent but there is no guarantee of its long term success).

(2) In any case, this is not the problem of mailing lists or mail clients.

(3) Both forms of munging (both Yahoo's and the .INVALID approach), with
or without the X-Original-From header, do *not* make it seem as if a
message did not go through a mailing list. Indeed, they are simply ways
of making it clear who the original author of a message was whilst not
hiding that the message went through a mailing list.

See also below: I *do not* in fact think that this attacks DMARC.

> If mailing list could do it, so could phishers.

Scammers and spammers do what they can. They will do what they can
regardless of what other people do in order to continue operating
effectively.

One might also observe that if "p=reject" DMARC users effectively
externalise some aspects of their spam problem, it seems only
appropriate and pragmatic for the rest of us to similarly externalise
the problems so created.

> And if
> this became somewhat common, DMARC, to achieve its goal of confirming
> sender identity would need to add checking that.

Not necessarily. There are two aspects to DMARC's protection mechanism:
(1) What users of email from DMARC policy publishing domains see, and
(2) what mail servers do before the user sees the email (if the user
sees it at all).

Whilst mail client recognition of the X-Original-From header would alter
what users see (which is in fact a key goal in this context, not a bug),
DMARC would nevertheless still be effective in terms of its own design
goals in that mail servers could still adhere to DMARC and reject or
spamfilter non-compliant messages.

Why would this be harmless for mail lists but bad for spam? Because From
munging and mail client parsing of the X-Original-From header will not
impact on the automated effectiveness of DMARC in preventing users from
seeing spam: Spammers would still be left with the difficulty of
obtaining a valid DKIM header that aligns with their chosen From address
whereas legitimate mail lists would not have this problem.

To put it another way, spammers might well use X-Original-From but this
would not help them to get end users to see their spam emails if mail
servers block or spamfilter non-DMARC-compliant messages (whereas mail
lists emails would get through fine).

> The only possible option for that would be wrapping, where the wrapped
> message was EXACTLY as sent (thus no content filtering, and all
> additions are added to the wrapper, not the original message).

Yes, wrapping would be ideal but I reckon this would be even more
difficult in terms of mail client acceptance than X-Original-From would
be. In other words, getting mail clients to correctly view wrapped
messages is not going to happen any time soon but recognising and
parsing X-Original-From (if it is present) is an easier thing to code.

> The problem we are seeing is that we have domains that don't really need
> that restriction are using it, and the world is needing to figure out
> how to make this work.

I agree and the above (a combination of semantically useful From munging
and a programmatically parseable X-Original-From header that does *not*
interfere with automated DMARC filtering by mail servers) seems to me to
be the basis of an effective and de facto-standardisable workaround to it.

> The real solution, in my opinion, would be a standard that deals with
> how MUA display the senders of messages, and a system similar to https
> certificates where domains (or email addresses) that really need
> verification could get a certificate and be able to have their addresses
> displayed a "verified", email pretending to be from them but not
> properly signed could be rejected or marked suspicious, but most
> personal mail would just be unverified.  It should make it clear that
> any ESP that uses this has an obligation to let is users understand the
> rules, and that it users are not allowed to let 3rd parties (like
> mailing list or other 3rd party mailers) send on their behalf (unless
> the standard allows a given email address to provide a cert to a 3rd
> party it indicate they are an authorized remailer for them). This should
> deal with the phish problem, at least once people are taught to look for
> the verified icon from "important" sources.

A good idea in theory but I suspect it falls down on the user education
part. Most users don't learn.

The number of parties who would need to convert to it is also
problematic, but conceivably something like this might be a part of some
entirely new mail system, an as yet imaginary "MTPng" or similar.


-- 
Mark Rousell

PGP public key: http://www.signal100.com/markr/pgp
Key ID: C9C5C162