That is should be expected when people monkey around with long time
mail infrastructure. Its a bad idea and sets a terrible precedent by
alluding to the idea "its normal." No its not normal. It will be
exploited and probably its too late to put this one back if a few
mailing list packages are already doing it. If isolated, fine, but
it can't be IETF endorsed in any way.
YAHOO does not want people to use their domain without permission.
Period and the big gorilla has set the action in motion for many
others to follow suit with strong policies that with DMARC will bring
things because it lacks the definition for wider use cases. So we need
the fastest way to get this resolution out there -- a POLICY LOOKUP
METHOD with expanding use cases definitions that was long envisioned
since the git-go.
We been battling this for a long time and its really about what domain
(1st or 3rd party) do we want to receivers to lookup?
Well, one side wants receivers to look up some 3rd party trust entity
(ala SSL) and the other side says, fine, but we also want the
self-signing authority lookup as well - the ownership domain. There
are conflicts between the two because the 3rd party guy does not want
the 1st party guy to have any say over any its mail changes or
tampering and/or forwarding. This "corollary" was unfortunately
written into RFC5016.
10. SSP MUST NOT provide a mechanism that impugns the existence of
non-first party signatures in a message. A corollary of this
requirement is that the protocol MUST NOT link practices of first
party signers with the practices of third party signers.
INFORMATIVE NOTE: the main thrust of this requirement is that
practices should only be published for that which the publisher
has control, and should not meddle in what is ultimately the
local policy of the receiver.
Refs: Deployment Consideration, Section 4.3.
Unfortunately, this is still a strong desire. Which is fine, but they
don't want to even bother to ask the 1st party domain what does the
correct or bad transaction is expected to LOOK like. It is this
separation that the DKIM wants to maintain that has long held back the
resolution to this problem.
Keep it simple.
--
HLS
On 9/9/2014 1:50 PM, Steve Atkins wrote:
On Sep 9, 2014, at 1:39 AM, Stephen J. Turnbull <step...@xemacs.org> wrote:
Kelley, John writes:
1. Auto Forwards, principally where the email is munged in some way
causing DKIM to fail.
2. Mailing lists; although the big ones seem to be rewriting the From
(thanks).
From what I've seen on Mailman Project lists[1], your users may not feel
the same way, though. There have been complaints to list owners that
they're getting singled out (a popular Mailman feature, for example,
checks DMARC policy and munges From or wraps the message only if it's
p=reject).
Some of the changes that have been made to mailing lists to work
around DMARC have made them significantly less useful.
It unavoidably breaks the ability to search for emails or filter inbound
mail by author email address.
It also makes it hard / impossible to reply to the
author, or see what domain the author is associated with - though
that may be because the changes made by the mailing list operators
aren't as well done as they could be rather than something
unavoidable.
Cheers,
Steve
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--
HLS
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
