dmarc_moderation_action not working in 2.1.18
Hi,
I've upgraded our Mailman installation to 2.1.18-1 recently and noticed that the "dmarc_moderation_action" is not working.
We've setup a test list, and set the list to "Munge From" for "dmarc_moderation_action". Upon sending a test message in from either one of our Yahoo or AOL accounts the "From" field is being maintained as " username@yahoo.com" or "username@aol.com" respectively.
The "vette" log is indicating that DMARC is being detected, and other logs also report DMARC's existence, however the "Munge From" action is NOT being taken.
Any help or suggestions would be appreciated.
*** I searched the archives prior to posting this message, and the topics related to "dmarc_moderation_action" did not seem to cover exactly or resolve my issue. If you require more info, please let me know. ***
Best Regards, Peter Knowles TPN Solutions
Email: pknowles@tpnsolutions.com Phone: 604-229-0715 Skype: tpnsupport Website: http://www.tpnsolutions.com
On 06/12/2014 07:29 AM, Peter Knowles wrote:
We've setup a test list, and set the list to "Munge From" for "dmarc_moderation_action". Upon sending a test message in from either one of our Yahoo or AOL accounts the "From" field is being maintained as " username@yahoo.com" or "username@aol.com" respectively.
The "vette" log is indicating that DMARC is being detected, and other logs also report DMARC's existence, however the "Munge From" action is NOT being taken.
What happens if you set dmarc_moderation_action to Reject? If the other logs are Mailman logs, what exactly do they report?
Have you rearranged the handler pipeline, or do you have a custom pipeline for this list that you didn't update to insert the new WrapMessage handler. WrapMessage must be in the pipeline and should be immediately before ToOutgoing, and CookHeaders must be after Moderate
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Mark,
When I set the option to "reject" it rejects properly as expected. But when it's set to "munge from" it sends it out as if "Accept" was chosen.
Best Regards, Peter Knowles TPN Solutions
Email: pknowles@tpnsolutions.com Phone: 604-229-0715 Skype: tpnsupport Website: http://www.tpnsolutions.com
On Thu, Jun 12, 2014 at 11:46 AM, Mark Sapiro <mark@msapiro.net> wrote:
On 06/12/2014 07:29 AM, Peter Knowles wrote:
We've setup a test list, and set the list to "Munge From" for "dmarc_moderation_action". Upon sending a test message in from either one of our Yahoo or AOL accounts the "From" field is being maintained as " username@yahoo.com" or "username@aol.com" respectively.
The "vette" log is indicating that DMARC is being detected, and other
logs
also report DMARC's existence, however the "Munge From" action is NOT being taken.
What happens if you set dmarc_moderation_action to Reject? If the other logs are Mailman logs, what exactly do they report?
Have you rearranged the handler pipeline, or do you have a custom pipeline for this list that you didn't update to insert the new WrapMessage handler. WrapMessage must be in the pipeline and should be immediately before ToOutgoing, and CookHeaders must be after Moderate
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Mailman-Users mailing list Mailman-Users@python.org https://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-users/pknowles%40tpnsolution...
On 06/12/2014 01:41 PM, Peter Knowles wrote:
When I set the option to "reject" it rejects properly as expected. But when it's set to "munge from" it sends it out as if "Accept" was chosen.
Then the problem almost certainly has to be the pipeline. There is a new WrapMessage handler that must be in the pipeline.
Do you have a GLOBAL_PIPELINE setting in mm_cfg.py? If so, look at the setting in Defaults.py and make sure it contains the WrapMessage entry in the right place.
If not, try
bin/withlist LISTNAME
and then at the prompt enter m.pipeline. Does that return a value rather than AttributeError?
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Mark,
Inside mm_cfg.py, "GLOBAL_PIPELINE" has the following:
SpamDetect Approve Replybot Moderate Hold MimeDel Scrubber Emergency Tagger CalcRecips AvoidDuplicates Cleanse CleanseDKIM CookieHeaders ToDigest ToArchive AfterDelivery Acknowledge ToOutgoing
Best Regards, Peter Knowles TPN Solutions
Email: pknowles@tpnsolutions.com Phone: 604-229-0715 Skype: tpnsupport Website: http://www.tpnsolutions.com
On Thu, Jun 12, 2014 at 2:19 PM, Mark Sapiro <mark@msapiro.net> wrote:
On 06/12/2014 01:41 PM, Peter Knowles wrote:
When I set the option to "reject" it rejects properly as expected. But when it's set to "munge from" it sends it out as if "Accept" was chosen.
Then the problem almost certainly has to be the pipeline. There is a new WrapMessage handler that must be in the pipeline.
Do you have a GLOBAL_PIPELINE setting in mm_cfg.py? If so, look at the setting in Defaults.py and make sure it contains the WrapMessage entry in the right place.
If not, try
bin/withlist LISTNAME
and then at the prompt enter m.pipeline. Does that return a value rather than AttributeError?
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Mark,
In Defaults.py "GLOBAL_PIPELINE" has the following:
SpamDetect Approve Replybot Moderate Hold MimeDel Scrubber Emergency Tagger CalcRecips AvoidDuplicates CleanseDKIM CookieHeaders ToDigest ToArchive ToUsenet AfterDelivery Acknowledge WrapMessage ToOutgoing
Best Regards, Peter Knowles TPN Solutions
Email: pknowles@tpnsolutions.com Phone: 604-229-0715 Skype: tpnsupport Website: http://www.tpnsolutions.com
On Thu, Jun 12, 2014 at 2:27 PM, Peter Knowles <pknowles@tpnsolutions.com> wrote:
Mark,
Inside mm_cfg.py, "GLOBAL_PIPELINE" has the following:
SpamDetect Approve Replybot Moderate Hold MimeDel Scrubber Emergency Tagger CalcRecips AvoidDuplicates Cleanse CleanseDKIM CookieHeaders ToDigest ToArchive AfterDelivery Acknowledge ToOutgoing
Best Regards, Peter Knowles TPN Solutions
Email: pknowles@tpnsolutions.com Phone: 604-229-0715 Skype: tpnsupport Website: http://www.tpnsolutions.com
On Thu, Jun 12, 2014 at 2:19 PM, Mark Sapiro <mark@msapiro.net> wrote:
On 06/12/2014 01:41 PM, Peter Knowles wrote:
When I set the option to "reject" it rejects properly as expected. But when it's set to "munge from" it sends it out as if "Accept" was chosen.
Then the problem almost certainly has to be the pipeline. There is a new WrapMessage handler that must be in the pipeline.
Do you have a GLOBAL_PIPELINE setting in mm_cfg.py? If so, look at the setting in Defaults.py and make sure it contains the WrapMessage entry in the right place.
If not, try
bin/withlist LISTNAME
and then at the prompt enter m.pipeline. Does that return a value rather than AttributeError?
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On June 12, 2014 2:34:50 PM PDT, Peter Knowles <pknowles@tpnsolutions.com> wrote:
Mark,
In Defaults.py "GLOBAL_PIPELINE" has the following:
SpamDetect Approve Replybot Moderate Hold MimeDel Scrubber Emergency Tagger CalcRecips AvoidDuplicates
Cleanse is missing here. I am guessing this is a typo.
CleanseDKIM CookieHeaders ToDigest ToArchive ToUsenet AfterDelivery Acknowledge WrapMessage
WrapMessage is missing from your mm_cfg.py version. That's the problem.
ToOutgoing
On Thu, Jun 12, 2014 at 2:27 PM, Peter Knowles <pknowles@tpnsolutions.com> wrote:
Mark,
Inside mm_cfg.py, "GLOBAL_PIPELINE" has the following:
...
Do not redefine GLOBAL_PIPELINE in mm_cfg.py for exactly this reason.
It seems your intent is to remove ToUsenet from the pipeline. If this is correct, remove your definition of GLOBAL_PIPELINE from mm_cfg.py and instead put
GLOBAL_PIPELINE. remove('ToUsenet')
to avoid issues like this in the future.
-- Mark Sapiro <mark@msapiro.net> Sent from my Android phone with K-9 Mail. [Unpaid endorsement]
I'm having a similar problem, also using 2.1.18-1. Posts from a Yahoo user are bouncing on redelivery to him.
Jun 13 18:55:00 host postfix/smtp[15681]: 912BD520AB:
to=<user@yahoo.com>, relay=mta5.am0.yahoodns.net[98.138.112.33]:25,
delay=1.2, delays=0.05/0/0.25/0.92, dsn=5.7.9, status=bounced (host
mta5.am0.yahoodns.net[98.138.112.33] said: 554 5.7.9 Message not
accepted for policy reasons. See
http://postmaster.yahoo.com/errors/postmaster-28.html (in reply to
end of DATA command))I don't have a GLOBAL_PIPELINE in mm_cfg.py.
host mailman # grep PIPELINE Mailman/mm_cfg.py
host mailman # bin/withlist Test-list2
Loading list test-list2 (unlocked)
The variable `m' is the test-list2 MailList instance
>>> m.pipeline
Traceback (most recent call last):
File "<console>", line 1, in <module>
File "/usr/lib64/mailman/Mailman/MailList.py", line 146, in
__getattr__
raise AttributeError, name
AttributeError: pipeline
>>>
Finalizing
host mailman #General Options
from_is_list is Munge From
anonymous_list is NoPrivacy Options --> Sender Filters
dmarc_moderation_action is Munge From
dmarc_quarantine_moderation_action is YesThe GLOBAL_PIPELINE in Defaults.py looks ok to me: GLOBAL_PIPELINE = [ # These are the modules that do tasks common to all delivery paths. 'SpamDetect', 'Approve', 'Replybot', 'Moderate', 'Hold', 'MimeDel', 'Scrubber', 'Emergency', 'Tagger', 'CalcRecips', 'AvoidDuplicates', 'Cleanse', 'CleanseDKIM', 'CookHeaders', # And now we send the message to the digest mbox file, and to the arch and # news queues. Runners will provide further processing of the message, # specific to those delivery paths. 'ToDigest', 'ToArchive', 'ToUsenet', # Now we'll do a few extra things specific to the member delivery # (outgoing) path, finally leaving the message in the outgoing queue. 'AfterDelivery', 'Acknowledge', 'WrapMessage', 'ToOutgoing', ]
Any ideas what I could try?
Thanks
glen
On 06/12/2014 02:19 PM, Mark Sapiro wrote:
On 06/12/2014 01:41 PM, Peter Knowles wrote:
When I set the option to "reject" it rejects properly as expected. But when it's set to "munge from" it sends it out as if "Accept" was chosen.
Then the problem almost certainly has to be the pipeline. There is a new WrapMessage handler that must be in the pipeline.
Do you have a GLOBAL_PIPELINE setting in mm_cfg.py? If so, look at the setting in Defaults.py and make sure it contains the WrapMessage entry in the right place.
If not, try
bin/withlist LISTNAME
and then at the prompt enter m.pipeline. Does that return a value rather than AttributeError?
On 06/13/2014 08:07 PM, glen martin wrote:
I'm having a similar problem, also using 2.1.18-1. Posts from a Yahoo user are bouncing on redelivery to him.
Jun 13 18:55:00 host postfix/smtp[15681]: 912BD520AB: to=<user@yahoo.com>, relay=mta5.am0.yahoodns.net[98.138.112.33]:25, delay=1.2, delays=0.05/0/0.25/0.92, dsn=5.7.9, status=bounced (host mta5.am0.yahoodns.net[98.138.112.33] said: 554 5.7.9 Message not accepted for policy reasons. See http://postmaster.yahoo.com/errors/postmaster-28.html (in reply to end of DATA command)) ...
General Options
from_is_list is Munge From anonymous_list is No
Privacy Options --> Sender Filters
dmarc_moderation_action is Munge From dmarc_quarantine_moderation_action is Yes
with the above, your list should be munging the From: on all outgoing messages because from_is_list is Munge From. The dmarc_moderation_action of Munge From is redundant in this case. It would serve to munge the
From only on messages originally from domains with DMARC p=reject or quarantine if from_is_list were No.
So the first question is what does the From: look like on messages from the list. Is it
From: Jane User <user@yahoo.com>
(which is not what it should be - something is wrong) or is it
From: Jane User via LISTNAME list <listname@mailman.host>
which is what it should be. If it is the latter, and your mailman.host does not publish a DMARC policy, then Yahoo is not rejecting the mail for DMARC, but for some other unknown to me reason, but Mailman is doing what it can.
If the From: is not munged, then there is a Mailman issue we can investigate. So which is it?
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
The From was not being munged, it was showing up as
From: Jane User <user@yahoo.com>
However, I noticed some other problems so I rebooted the host just to make sure every change had fully taken hold .. and things are working now. So it is strange, while I had previously restarted mailman, something was still not working right until a reboot. Maybe a problem in my init scripts.
thx
glen
On 06/13/2014 09:02 PM, Mark Sapiro wrote:
On 06/13/2014 08:07 PM, glen martin wrote:
I'm having a similar problem, also using 2.1.18-1. Posts from a Yahoo user are bouncing on redelivery to him.
Jun 13 18:55:00 host postfix/smtp[15681]: 912BD520AB: to=<user@yahoo.com>, relay=mta5.am0.yahoodns.net[98.138.112.33]:25, delay=1.2, delays=0.05/0/0.25/0.92, dsn=5.7.9, status=bounced (host mta5.am0.yahoodns.net[98.138.112.33] said: 554 5.7.9 Message not accepted for policy reasons. See http://postmaster.yahoo.com/errors/postmaster-28.html (in reply to end of DATA command))... General Options
from_is_list is Munge From anonymous_list is NoPrivacy Options --> Sender Filters
dmarc_moderation_action is Munge From dmarc_quarantine_moderation_action is Yeswith the above, your list should be munging the From: on all outgoing messages because from_is_list is Munge From. The dmarc_moderation_action of Munge From is redundant in this case. It would serve to munge the From only on messages originally from domains with DMARC p=reject or quarantine if from_is_list were No.
So the first question is what does the From: look like on messages from the list. Is it
From: Jane User <user@yahoo.com>
(which is not what it should be - something is wrong) or is it
From: Jane User via LISTNAME list <listname@mailman.host>
which is what it should be. If it is the latter, and your mailman.host does not publish a DMARC policy, then Yahoo is not rejecting the mail for DMARC, but for some other unknown to me reason, but Mailman is doing what it can.
If the From: is not munged, then there is a Mailman issue we can investigate. So which is it?
participants (3)
-
glen martin -
Mark Sapiro -
Peter Knowles