John Levine writes:
> Before you tell me I'm nuts, hear me out. I've actually implemented
> this, and it works.
You're not nuts. However, your definition of "works" is necessarily
limited to what you personally can see, in only a couple of weeks. It
does *not* take into account the potential damage to interoperability
over time of this hack becoming wide-spread.
> Advantages:
>
> * Really fixes DMARC problems
That's a matter of opinion. The DMARC-using domains will disagree, I
think, as it still means that you are "impersonating" their users (see
below), and making DMARC ineffective as a means of reducing spam and
phishing. But we'll see about that soon enough.
Disadvantages:
The big one is that we can only guess what the long-run consequences
are going to be. In particular, I think in the short-run we can
definitely foresee (1) spreading invalid addresses, which will bounce
if automatically inserted as destination addresses, all over the net,
possibly creating more backscatter, and (2) a tendency for people to
see "@yahoo.com.invalid" as a *valid* form of Yahoo! address
("computers are so weird"). Tools, most of them simple, will be
created to hide and to strip ".invalid" automatically, meaning you can
hide any arbitrary domain from DMARC behind ".invalid". Spammers and
phishers will pick up on this, with an eventual adverse effect on your
lists' ability to deliver mail (not to mention whatever responsibility
we have for any victims we have trained to ignore ".invalid").
Note that these effects, if operational, tend to hurt everybody on the
net. Removing yahoo.com, and other domains with "p=reject" policies,
entirely from "From" hurts Yahoo! users and people who want to
communicate with Yahoo! users, but really, the bad effects will stop
there, I think. Yahoo! gets what conspiracy theorists (Hi, Lindsay!)
think they want, namely locking their users into Yahoo! groups, but I
think they're going to find that the opposite effect (of annoying
their users so they move to a more flexible domain) is more important,
and DMARC will fall of its own weight without leaving too much of a
mark on the rest of the mail system.
OTOH, the natural response of the DMARC folks is going to be to try to
control this. I can't imagine, if they succeed in agreeing on how to
do so, that it will cause less damage to interoperability than their
current behavior.
My bottom line is that I would prefer not teaching Mailman to violate
RFC 5322 at all (yes, I know that ship has long since sailed), and if
we must we should limit it to what the "owners" of those addresses
recommend.
Remember, the DMARC people are by and large employed by companies with
*no vested interest* in the continued success of the email system,
especially for forums: in most cases they'd be happier if mailing lists
(and newsgroups) went away and their users were locked into their web
forums. We, on the other hand, depend very much on the smooth working
of the email system -- the only effect of fighting fire with fire is
to increase the damage *we* suffer from first- to second-degree burns.
If third parties' experiments with .invalid become overwhelmingly
popular, then practically speaking Mailman will cave on an option to
munge From by appending ".invalid" the same way it had to cave on
Reply-To munging. But let's not lead the charge of the Light Brigade.
Regards,
Steve
_______________________________________________
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
