--On Monday, April 14, 2014 01:08 -0700 Doug Barton
<dougb@xxxxxxxxxxxxx> wrote:
>> But this takes us back to Ned's point (or at least my
>> interpretation of it): it is lots easier to fix a bad DMARC
>> config, ignore restrictive DMARC specifications, or even to
>> abandon DMARC entirely, than it is to believe that we can
>> upgrade every MTA and MUA on the network to start accepting
>> percent hacks, bang paths, or the syntax characters used to
>> denote them, again. Or any other strange local-part syntax
>> anyone is likely to come up with, e.g., perhaps we could use
>> plus signs, hyphens, or appropriately-escaped backslashes. Or
>> we could steal "/" and "=" back from X.400 gateways. Right.
>
> Well + is out, since that's used by various local filtering
> solutions.
Doug, I think you are missing my, and probably John Levine's,
attempts at humor. Let me spell it out:
The point was the "+" is used in local filtering and, perhaps
more generally, as subaddresses with all sorts of applications.
Both "%" and "!", along with <@a:x@y>, were, at different points
and gateways to different systems, mail routing mechanisms that
are now sufficiently deprecated and/or rare that many
intermediate MTAs will singly reject or drop messages containing
them. "/" and "=" were used on the local part of addresses
bound for, or coming from, X.400 gateways and many systems will
reject (or possibly) drop messages with local parts in which
they appear but that don't conform to that gateway syntax...
except that "/" may also designate delivery to a file and "//"
may be a piece of ancient JCL.
It isn't just the MTAs: Some POP and IMAP client MUAs will trash
this stuff too. As with the MTAs, using these sorts of trick
conventions without disrupting the existing mail systems,
including those that don't pay any attention to DMARC or DKIM
headers and hence are unaffected by the problem, requires that
everything be upgraded and upgraded more or less on a flag day
basis.
There is a strong rule in RFC 5321 and its predecessor
forbidding anything but the final delivery system from rewriting
a local-part and it is there precisely because one doesn't know
what sorts of conventions and indicates were begin used there.
The bottom line is that trying to work around this by a trick
syntax convention is really hard, unlikely to succeed, and quite
likely to result in legitimate messages disappearing and/or
breaking existing conforming systems.
> But your point is well taken ... the "right" answer may be to
> fix or discard DMARC, I honestly don't know. But in a world
> where DMARC is here to stay, or if not DMARC then some other
> anti-spam solution that breaks mailing list forwarding; and in
> that same world where mailing list traffic is negligible (and
> therefore the cost of breaking mailing lists is in the noise
> compared to the benefits of deploying said anti-spam solution)
> it's incumbent on the mailing list software folks to solve
> this problem.
I'm going to risk more humor and suggest that everyone who
believes that mailing list traffic is negligible and the cost of
breaking them is in the noise should be immediately unsubscribed
from all IETF-related lists, including this one.
best,
john