Mark Rousell writes:
> I do not think that this method of working around Yahoo's DMARC
> implementation will necessarily
Nor do I. I point to the *possibility* and our lack of ability to
predict effects. The RFCs have proven over time to give us a system
that works smoothly. We have rules of thumb that help to understand
why they work as well as they do, but the most important one is that
RFCs must be shown to work in practice before they become Proposed
Standards. Ie, don't expect something to work until you see it.
> it can also be argued (more persuasively in my opinion) that
> "yahoo.com.INVALID" or "yahoo.com.REMOVEME" or similar is quite
> clearly not impersonating any valid Yahoo user *when sent from a
> mail list*.
Ah, but what matters here is not your opinion or mine, nor even those
of the DMARC folks or the sysadmins at Yahoo. What matters is what
"just plain folks" think. Remember, according to AOL, 2% of such
users were suckered by the recent phishing attack at AOL, and that
presumably translates to around 50,000 users! If 2% of those 2% adopt
the interpretation I fear they will, that's 1000 users. I'm not
willing to allow Mailman to be (partly) responsible for that without
trying to find a much better way first.
> But do they actually need to? As I understand it, they wish to use DMARC
> to prevent spam that impersonates or spoofs their users or clients.
> Spammers who strip off munged email suffixes and spoof-send using the
> unmunged email address will indeed be blocked by DMARC.
No, that's the whole point. They will *not* strip the suffix, and
instead prefix the phishing attack with
We have repeatedly attempted to reach your email address, but our
mail has been rejected due to your ISP's DMARC configuration.
Thus we have used the .invalid convention to work around this
problem for this important message.
You saw it here first! And don't think that the phishers are too dumb
to figure it out for themselves. N.B. This trick doesn't work if the
list-post address is in From.
> The recommendations that dmarc.org makes for mailing list providers at
> http://dmarc.org/faq.html#s_3 could be helpful in some cases but do not
> address the full issue that adding a suffix is intended to work around
> (and it is an issue which *needs* be to worked around somehow).
The wrap_message feature implemented in Mailman 2.1.18 is such a
workaround. It completely takes "ownership" (aargh!) of the message
in a way which is 100% RFC-conformant and causes no loss of
information.
The main problem is that it is known to be inconvenient for users of
at least some versions of the Apple MUA on iPhones (in general, for
anybody whose MUA can't handle MIME digests well).
> Adding suffixes seems like a kludge but a not unreasonable one and it is
> also one that should not negatively impact DMARC or users of DMARC, as
> far as I can see.
That is not good enough for me. When you can say, "here's a $10,000
prize for the first report of a serious negative effect of this
kludge, and it's in escrow with a reputable service", then I'll
consider this kind of argument. $10,000 is a quite reasonable
criterion, given that if you're wrong, you may be causing $1 worth of
annoyance to each of 500 million people.
_______________________________________________
Mailman-Developers mailing list
Mailman-Developers@python.org
https://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives:
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe:
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org
Security Policy: http://wiki.list.org/x/QIA9
