I'm a list software product developer. I believe our list package was
among the
first to implement domains controls with restrictive domains. In our
case, we used the then IETF Proposed Standard ADSP. It followed the
guidelines written in the 2006 DSAP (DKIM Signature Authorization
Protocol) I-D section 3.3:
3.3. Mailing List Servers
Mailing List Servers (MLS) applications who are compliant with DKIM
and DSAP operations, SHOULD adhere to the following guidelines:
Subscription Controls
MLS subscription processes should perform a DSAP check to
determine if a subscribing email domain DSAP policy is restrictive
in regards to mail integrity changes or 3rd party signatures. The
MLS SHOULD only allow original domain policies who allow 3rd party
signatures.
Message Content Integrity Change
List Servers which will alter the message content SHOULD only do
so for original domains with optional DKIM signing practices and
it should remove the original signature if present. If the List
Server is not going to alter the message, it SHOULD NOT remove the
signature, if present.
The main point is that there should be no advocation or promoting what
is effectively violating a security protocol, especially of that being
advocated with a 5322.From rewrite.
I think its an unethical practice to be bypassing a security protocol,
intentionally. Its bound to bite you. And what about the domains that
don't want you to do this? Unless there is a permission based concept
to do this, it is a terrible mistake to open up this door. You won't
be able to trust any domain and From rewrites would cause the lost of
any protective value the message originally had. What is to suggest
that the receiving domains won't learn to adapt to detect these
"rewrite/rewrap" loopholes and begin to give such senders bad
reputation blocks?
Overall, the hurdle to is to get systems to do a LOOKUP in order to
get permission to resign. If you assume this is going to be the case,
then we don't to be kludging radical methods simply to bypass a
security the originating domain does not want you to do anyway. Thats
a pretty risky thing to do. I certainly can't support these ideas to
rewrite lacking permission to do considerations and against the wishes
of the originating domain.
--
HLS
[1]
http://isdg.net/public/ietf/drafts/draft-santos-dkim-dsap-01.html#anchor14
On 6/2/2014 3:28 AM, Stephen J. Turnbull wrote:
Tony Hansen writes:
> I would love to see that list of multiple mitigations shared with the
> broader community. That would be useful information for people in the
> IETF,
I've shared it here in various levels of detail more than once, and
sooner or later it will be in the Mailman FAQ as I'm sure that the
brief descriptions in the admin UI will need amplification.
Basically, Mailman provides two orthogonal features:
1. Whether to mitigate, and when to mitigate, that is the question
a. Don't.
b. Always.
c. Only for posters from DMARC "p=reject" domains.
2. How to mitigate:
a. Replace poster with list in From:, and diddle Reply-To so that
reply-to-poster is as convenient as possible.
b. Wrap the message in a MIME message/rfc822 body.
Thanks to John Levine, we'll eventually have a 2c option: append
.INVALID to the poster's mailbox in From:.
> as well as other MLM teams not involved wherever those discussions
> occurred.
AFAIK there is no particular place where MLM teams meet up; there are
very few interoperation considerations. I would think other MLM teams
would be here now if they cared (cf John Levine's comment on your post).
> Perhaps there is one or more of those solutions that we SHOULD be
> recommending.
The only solution currently available I can see recommending is
banning domains that DoS third parties. However, that isn't going to
fly on many, probably the great majority, of Mailman and ListServ
lists. (Majordomo, smartlist, and whatever is used with qmail may
have a rather different user population, as is suggested by John's
observation.)
All the others have defects that some people consider severe, so will
have to be chosen by the list's administration.
> And perhaps broader discussions will provide an AHA moment where we see
> a way to solve BOTH MLM's problems AND DMARC's problems with MLMs in the
> face of a p=reject policies.
My personal belief (as previously mentioned) is that that is a logical
impossibility. But we can hope I'm wrong!
> Are the current p=reject semantics totally correct? As has been pointed
> out by others, even with mail sent out from banks, there are legitimate
> uses of mailing lists or things like mailing lists where you want copies
> to be received by multiple people.
The important thing is that the banks' problems with "p=reject" can be
solved (worked around, if you prefer) by the banks, without
cooperation of third parties, and without (much) harm to third parties
(it's unlikely that there are Mailman lists where 314 bank reps will
post to the same list in a week and so knock all subscribers into
disabled state).
While it would be as nice as getting a pony for the banks' tech staff
to be able to post to this list from the well-known domain, I don't
think that's very high on their list of tasks for their techies. Just
registering a "somebank-inc.com" domain is satisfactory, I suppose.
> Or alternatively, perhaps p=reject needs to be redefined slightly to
> take advantage of specific recommended practices for mailing lists.
Perhaps. I'm a fan of "simple protocols used judiciously"
vs. "complex protocols that try to forestall all problems" myself.
If complexity would make it possible for Yahoo! to use "p=reject"
without DoS'ing mailing list subscribers and their own posters, it
would be worth it, I suppose.
> > SPF and DKIM are now ancient history, at least as far as Mailman
> > development goes. We've already done what's technically
> > possible.
>
> Since I'm not privy yet to what all GNU Mailman has chosen to do in
> the face of SPF and DKIM, so I don't know how to evaluate that
> statement. Sorry.
>
> If you're saying that you've thrown out all use of DKIM, I consider that
> a sorry state of affairs.
No. What we've done is
(1) Put up a FAQ encouraging re-signing by MTAs hosting lists.
(2) Added an option to strip the (presumably broken, we don't check
for it) original DKIM signature.
There's no real point in MLMs doing more than that as it requires
cooperation from the domain's DNS. OAR (which I don't think is worth
it) could be done, but I think this probably is better done by the MTA
(local MUAs and admins might wish to refer to it).
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
