Re: [Mailman-Developers] Camera-ready option to mitigate DMARC issues

2016-11-05 Thread Mark Sapiro
On 11/05/2016 04:11 AM, Alessandro Vesely wrote:
> 
> The idea is to add a footer only in case it is not present, similar to
> what is done with subject_prefix.  By properly setting both of them, a
> sender can submit what can be called a camera-ready post.  Since no
> change applies, no DKIM signature breaks.  Hence,
> dmarc_moderation_action is not needed for such posts.  It is not even
> necessary to check author's domain policy.


Mailman could conceivably keep track of whether it has changed any
headers or anything in the body of the post, but it's more complicated
than that. The first big problem is the Munge From or Wrap Message
transformations are applied before any msg_header or msg_footer is added
(or maybe added).

I.e. in both MM 2.1 and MM 3, the DMARC mitigations are applied in the
incoming handler pipeline before the message is queued for delivery
processing. Various decorations such as adding msg_header and msg_footer
and modifying To: depend on "personalization" and have to be done by
delivery processing on a per-recipient basis. In fact, the "camera
ready" notion can't apply to any post that is going to be personalized
in any way. This in itself would limit the usefulness.

It would be more feasible to do this by the poster adding a
"X-Camera-Ready:" header to the post saying don't transform my message,
but this is unacceptable as it would bypass content filtering,
personalization and various other things.


> I'm not familiar with Mailman administration, so I ask your opinion. 
> How long would it take to code this option?


How many angels can dance on the head of a pin?


> How useful would it be?


In my opinion, certainly not enough to justify the effort in trying and
the inevitable bug reports that would follow from all the edge cases.


> Camera-ready posts would be created by hands, by cleverly configuring
> some email client, or by using purposely written add-ons.  They could
> also be done by MSAs who care about the damage they cause by publishing
> p=reject --the process can certainly be standardized and automated.


How does the sender's automated process even know what msg_header and
msg_footer will be added by the list?

-- 
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan
___
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


Re: [Mailman-Developers] MM3 DMARC mitigations

2016-11-05 Thread David Andrews

At 11:06 AM 11/5/2016, Mark Sapiro wrote:


However, I've just become aware that Microsoft has implemented another
"feature". So far, the info I have is this is limited to their "hosted
mail services", but it may well spread. What they are doing is looking
at incoming mail for signs of spoofing/phishing and if found, they place
a prominent notice

This sender failed our fraud detection checks and may not be who they
appear to be. Learn about spoofing

in the message. The issue for us is that one of the tests is the To: and
From: addresses are the same. That means that any message To: a list
with DMARC mitigations applied will be sent From: the list and any
recipients using these Microsoft services will see that warning in the
list message[1].

How long will it be before this spreads to all Microsoft email services
?


This message has started appearing on messages on a list I subscribe 
to at work, the state of MN, and they use hosted office 365 etc., and 
the messages are almost always from legitimate senders, so going to 
be a problem.


Dave


___
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


[Mailman-Developers] Camera-ready option to mitigate DMARC issues

2016-11-05 Thread Alessandro Vesely

Dear all,
I'd like to probe the feasibility of this option.

The idea is to add a footer only in case it is not present, similar to what is 
done with subject_prefix.  By properly setting both of them, a sender can 
submit what can be called a camera-ready post.  Since no change applies, no 
DKIM signature breaks.  Hence, dmarc_moderation_action is not needed for such 
posts.  It is not even necessary to check author's domain policy.


I'm not familiar with Mailman administration, so I ask your opinion.  How long 
would it take to code this option?  How useful would it be?


Camera-ready posts would be created by hands, by cleverly configuring some 
email client, or by using purposely written add-ons.  They could also be done 
by MSAs who care about the damage they cause by publishing p=reject --the 
process can certainly be standardized and automated.


TIA for any reply, and thanks for a great product
Ale
___
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


Re: [Mailman-Developers] MM3 DMARC mitigations

2016-11-05 Thread Mark Sapiro
On 10/31/2016 03:08 PM, Eric Searcy wrote:
> 
> That reminds me.  I have a proposed idea for another nice-to-have, that
> I'm mentioning now in case it has any impact on the architecture you are
> describing.  Some email systems (e.g. Exchange) do not accept any
> inbound email crossing their edge that uses their own From domain.  It's
> like a tiny microcosm of DMARC but only for their domain, and there is
> no way for the outside world to know about their policy.  However, when
> a member of the community says they get all list messages *except those
> from their colleagues*, it's clear they have this kind of setup.  It
> would be great to have a customizable-by-sender-domain munge-or-wrap
> filter that let me add other domains to get the same treatment as
> domains that don't publish DMARC -- even if not needed for general
> receipt of their messages, so that emails to others at the same domain
> on the list can be received.  (This functionality doesn't exist in mm2
> either.)


Adding Mailman-Developers to the recipients.

As I noted in the original thread, this would not be difficult to add,
but it won't be in the initial implementation of DMARC mitigations for
MM 3 (see  for
more on that).

However, I've just become aware that Microsoft has implemented another
"feature". So far, the info I have is this is limited to their "hosted
mail services", but it may well spread. What they are doing is looking
at incoming mail for signs of spoofing/phishing and if found, they place
a prominent notice

This sender failed our fraud detection checks and may not be who they
appear to be. Learn about spoofing

in the message. The issue for us is that one of the tests is the To: and
From: addresses are the same. That means that any message To: a list
with DMARC mitigations applied will be sent From: the list and any
recipients using these Microsoft services will see that warning in the
list message[1].

How long will it be before this spreads to all Microsoft email services
?


[1] I first became aware of this via the thread at
.
There it was the poster who saw the warning in his copy of the list
message and mistakenly thought it was a rejection of his post to the
list. The reply at

has interesting info.

-- 
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan



signature.asc
Description: OpenPGP digital signature
___
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