Somewhat OT: DMARC and this list

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Somewhat OT: DMARC and this list

Dianne Skoll
Hi,

Tons of list traffic keeps getting quarantined because of DMARC.  For
example, a recent message from David Jones <[hidden email]>:

DMARC policy for domain ena.com suggests Rejection as
DMARC_POLICY_REJECT, but quarantined due to rule settings

$ host -t txt _dmarc.ena.com
_dmarc.ena.com descriptive text "v=DMARC1\; p=reject\; sp=reject\; rua=mailto:[hidden email]\;"

(In this instance, we've overridden the DMARC policy and converted it
to quarantine instead of reject, so I was able to retrieve the email, but...)

I'm pretty sure Mailman can do DMARC-munging.  Can ezmlm do the equivalent
of Mailman's "ALLOW_FROM_IS_LIST" feature?

Regards,

Dianne.
Reply | Threaded
Open this post in threaded view
|

Re: Somewhat OT: DMARC and this list

David Jones
>From: Dianne Skoll <[hidden email]>
   
>Tons of list traffic keeps getting quarantined because of DMARC.  For
>example, a recent message from David Jones <[hidden email]>:

>DMARC policy for domain ena.com suggests Rejection as
>DMARC_POLICY_REJECT, but quarantined due to rule settings

>$ host -t txt _dmarc.ena.com
>_dmarc.ena.com descriptive text "v=DMARC1\; p=reject\; sp=reject\; rua=mailto:[hidden email]\;"

>(In this instance, we've overridden the DMARC policy and converted it
>to quarantine instead of reject, so I was able to retrieve the email, but...)

>I'm pretty sure Mailman can do DMARC-munging.  Can ezmlm do the equivalent
>of Mailman's "ALLOW_FROM_IS_LIST" feature?

I found this:
https://blogs.apache.org/infra/entry/dmarc_filtering_on_lists_that

so let me open a Jira ticket to see if we need to get that setting enabled.

Dave
Reply | Threaded
Open this post in threaded view
|

Re: Somewhat OT: DMARC and this list

Benny Pedersen-2
In reply to this post by Dianne Skoll
Dianne Skoll skrev den 2017-05-19 20:30:

> I'm pretty sure Mailman can do DMARC-munging.  Can ezmlm do the
> equivalent
> of Mailman's "ALLOW_FROM_IS_LIST" feature?

some maillists break DKIM, forkus on that first, not last !

if you get this message here with DMARC fail, blame the maillist break
DKIM

but i am pretty sure it gets DMARC pass on my mail returned here

time will tell :=)

mailman sooks btw on dkim/dmarc
Reply | Threaded
Open this post in threaded view
|

Re: Somewhat OT: DMARC and this list

Dianne Skoll
On Fri, 19 May 2017 20:43:39 +0200
Benny Pedersen <[hidden email]> wrote:

> some maillists break DKIM, forkus on that first, not last !

Thank you for not adding any value to the conversation.  The
domain in question is not using DKIM.

Regards,

Dianne.
Reply | Threaded
Open this post in threaded view
|

Re: Somewhat OT: DMARC and this list

Benny Pedersen-2
In reply to this post by David Jones
David Jones skrev den 2017-05-19 20:38:

> so let me open a Jira ticket to see if we need to get that setting
> enabled.

Authentication-Results: linode.junc.eu; dmarc=fail (p=reject dis=none)
header.from=ena.com
Authentication-Results: linode.junc.eu; dkim=none; dkim-atps=neutral

where is the dkim signing ?

hopefullly mailman stops removing dkim keys header

try post on postfix maillist, did it fail there ?, if yes make local bug
fix on it, if it did get dmarc pass be happy
Reply | Threaded
Open this post in threaded view
|

Re: Somewhat OT: DMARC and this list

Benny Pedersen-2
In reply to this post by Dianne Skoll
Dianne Skoll skrev den 2017-05-19 20:47:

> Thank you for not adding any value to the conversation.  The
> domain in question is not using DKIM.

okay, my fault then, but this is not a error if not using reject, but it
is if dmarc policy is reject

hope its clear now
Reply | Threaded
Open this post in threaded view
|

Re: Somewhat OT: DMARC and this list

Alan Hodgson
In reply to this post by Dianne Skoll
On Friday 19 May 2017 14:47:56 Dianne Skoll wrote:
> On Fri, 19 May 2017 20:43:39 +0200
>
> Benny Pedersen <[hidden email]> wrote:
> > some maillists break DKIM, forkus on that first, not last !
>
> Thank you for not adding any value to the conversation.  The
> domain in question is not using DKIM.
>

This is actually one of the few mailing lists that a DMARC p=reject domain can
send anything to. Assuming they DKIM-sign their mail, of course.

I would argue that setting a DMARC p=reject policy without working DKIM is
fundamentally broken idea on the sender's part. They can't send bounces or
vacation messages or anything else with a null envelope sender, for starters.
Or send anything to anyone who forwards their mail to Gmail, at least ....

I guess you can whitelist them if you care enough.
Reply | Threaded
Open this post in threaded view
|

Re: Somewhat OT: DMARC and this list

Dianne Skoll
On Fri, 19 May 2017 12:00:29 -0700
Alan Hodgson <[hidden email]> wrote:

> This is actually one of the few mailing lists that a DMARC p=reject
> domain can send anything to. Assuming they DKIM-sign their mail, of
> course.

Yep.

> I would argue that setting a DMARC p=reject policy without working
> DKIM is fundamentally broken idea on the sender's part.

Seconded.  The gluing of SPF onto DMARC is a mess.

Regards,

Dianne.
Reply | Threaded
Open this post in threaded view
|

Re: Somewhat OT: DMARC and this list

David B Funk
In reply to this post by Dianne Skoll
On Fri, 19 May 2017, Dianne Skoll wrote:

> Hi,
>
> Tons of list traffic keeps getting quarantined because of DMARC.  For
> example, a recent message from David Jones <[hidden email]>:
>
> DMARC policy for domain ena.com suggests Rejection as
> DMARC_POLICY_REJECT, but quarantined due to rule settings
>
> $ host -t txt _dmarc.ena.com
> _dmarc.ena.com descriptive text "v=DMARC1\; p=reject\; sp=reject\; rua=mailto:[hidden email]\;"
>
> (In this instance, we've overridden the DMARC policy and converted it
> to quarantine instead of reject, so I was able to retrieve the email, but...)
>
> I'm pretty sure Mailman can do DMARC-munging.  Can ezmlm do the equivalent
> of Mailman's "ALLOW_FROM_IS_LIST" feature?
>
> Regards,
>
> Dianne.

My read on this is that "@ena.com" is living dangerously. They publish SPF
records and DMARC records (with p=reject) but do NOT DKIM sign their mail.

In general it's dangerous to expect SPF to work thru a maillist or other
forwarder. Often DKIM will but you cannot count on it (particularly if the list
engages in Subject munging).

If they're only going to use SPF then publishing a DMARC policy of "reject" is
risky.
See: https://dmarc.org/2017/03/can-i-use-dmarc-if-i-have-only-deployed-spf/

Please let me know if I'm misinterpreting the signs.

Dave

--
Dave Funk                                  University of Iowa
<dbfunk (at) engineering.uiowa.edu>        College of Engineering
319/335-5751   FAX: 319/384-0549           1256 Seamans Center
Sys_admin/Postmaster/cell_admin            Iowa City, IA 52242-1527
#include <std_disclaimer.h>
Better is not better, 'standard' is better. B{
Reply | Threaded
Open this post in threaded view
|

Re: Somewhat OT: DMARC and this list

RW-15
On Fri, 19 May 2017 14:13:22 -0500 (CDT)
David B Funk wrote:

ne.  
>
> My read on this is that "@ena.com" is living dangerously. They
> publish SPF records and DMARC records (with p=reject) but do NOT DKIM
> sign their mail.

Most of them pass DKIM, a minority aren't signed.
Reply | Threaded
Open this post in threaded view
|

Re: Somewhat OT: DMARC and this list

David Jones
>From: RW <[hidden email]>
   
>On Fri, 19 May 2017 14:13:22 -0500 (CDT)
>David B Funk wrote:

>ne. 
>>
>> My read on this is that "@ena.com" is living dangerously. They
>> publish SPF records and DMARC records (with p=reject) but do NOT DKIM
>> sign their mail.

>Most of them pass DKIM, a minority aren't signed.

My edge mail servers are DKIM signing properly for ena.com.  I am
able to send to Gmail and "Show Original" says:

SPF: PASS with IP 96.5.1.12
DKIM: PASS with domain ena.com
DMARC: PASS

I guess the envelope-from is changed to the Mailman list which
would break the SPF alignment and it could be stripping out the
DKIM headers if you all are saying it's not there.

I guess I will have to sign up with my personal email address that
doesn't have p=reject.  I guess as more an more domains move to
p=reject, then this is going to be a real problem.  Mailing lists are
going to have to evolve how they send or something.

Dave
   
Reply | Threaded
Open this post in threaded view
|

Re: Somewhat OT: DMARC and this list

David B Funk
In reply to this post by RW-15
On Fri, 19 May 2017, RW wrote:

> On Fri, 19 May 2017 14:13:22 -0500 (CDT)
> David B Funk wrote:
>
> ne.
>>
>> My read on this is that "@ena.com" is living dangerously. They
>> publish SPF records and DMARC records (with p=reject) but do NOT DKIM
>> sign their mail.
>
> Most of them pass DKIM, a minority aren't signed.

Urgg, I see that now. I looked at a few of David Jones' posts to this list and
saw that they weren't DKIM signed, so I extrapolated that to a general
asumption.

I see that they're using Office-365. This is one of the issues I have with
0-365, it's a black box which is hard to second guess.
Sometimes they DKIM sign, some times they don't.
Sometimes they will score incoming messasge that are properly DKIM signed as
spam (for no reason other than the DKIM signature, as far as I can tell).

Bottom line; If you put yourself at the mercy of Office-365, using a DKIM policy
of "reject" is risky.



--
Dave Funk                                  University of Iowa
<dbfunk (at) engineering.uiowa.edu>        College of Engineering
319/335-5751   FAX: 319/384-0549           1256 Seamans Center
Sys_admin/Postmaster/cell_admin            Iowa City, IA 52242-1527
#include <std_disclaimer.h>
Better is not better, 'standard' is better. B{
Reply | Threaded
Open this post in threaded view
|

Re: Somewhat OT: DMARC and this list

David Jones
>From: David B Funk <[hidden email]>
   
>On Fri, 19 May 2017, RW wrote:

>> On Fri, 19 May 2017 14:13:22 -0500 (CDT)
>> David B Funk wrote:
>>
>> ne.
>>>
>>> My read on this is that "@ena.com" is living dangerously. They
>>> publish SPF records and DMARC records (with p=reject) but do NOT DKIM
>>> sign their mail.
>>
>> Most of them pass DKIM, a minority aren't signed.

>Urgg, I see that now. I looked at a few of David Jones' posts to this list and
>saw that they weren't DKIM signed, so I extrapolated that to a general
>asumption.

They are DKIM signed so something must be striping the headers.

>I see that they're using Office-365. This is one of the issues I have with
>0-365, it's a black box which is hard to second guess.
>Sometimes they DKIM sign, some times they don't.
>Sometimes they will score incoming messasge that are properly DKIM signed as
>spam (for no reason other than the DKIM signature, as far as I can tell).

>Bottom line; If you put yourself at the mercy of Office-365, using a DKIM policy
>of "reject" is risky.

I don't.  Our inbound to and outbound from Office 365 is handled by our
own mail servers that are properly DKIM signing.  I have been reviewing
DMARC reports for years now to make sure we had good SPF, DKIM and
DMARC before recently moving to p=reject.

Dave
Reply | Threaded
Open this post in threaded view
|

Re: Somewhat OT: DMARC and this list

Alan Hodgson
On Friday 19 May 2017 20:11:42 David Jones wrote:
> >Urgg, I see that now. I looked at a few of David Jones' posts to this list
> >and saw that they weren't DKIM signed, so I extrapolated that to a general
> >asumption.
>
> They are DKIM signed so something must be striping the headers.
>

Well, it's not the list. Others' signatures are coming through fine.

I had to tell OpenDMARC to whitelist ena.com to get anything from you.
Reply | Threaded
Open this post in threaded view
|

Re: Somewhat OT: DMARC and this list

Benny Pedersen-2
In reply to this post by David Jones
David Jones skrev den 2017-05-19 21:36:

> SPF: PASS with IP 96.5.1.12
> DKIM: PASS with domain ena.com
> DMARC: PASS

authentication-results: spamassassin.apache.org; dkim=none (message not
  signed) header.d=none;spamassassin.apache.org; dmarc=none action=none
  header.from=ena.com;

is something in your mailchain remove signed dkim ?

> I guess the envelope-from is changed to the Mailman list which
> would break the SPF alignment and it could be stripping out the
> DKIM headers if you all are saying it's not there.

no no no no and no, maillists does not break spf, what happend is that
domain change on every mta, so it could still pass spf even if your own
domain is not spf protected, but as you see it is really a forwared mail
til maillist that pass spf on apache.org

this is spf, but you miss still to dkim sign to the maillist, this is
your error if you like to make dmarc reject policy

problem with rfcs for dmarc is that its not possible to whitelist
maillists servers so thay never reject on policy reject, what would
happend if we all reject on a single domain that have policy reject ?,
then no one would be subscripbed at the end, if one like to follow own
rules on reject

it would be nice if dmarc could handle reject policy better if spf
passed, maybe lua scripted ?

> I guess I will have to sign up with my personal email address that
> doesn't have p=reject.  I guess as more an more domains move to
> p=reject, then this is going to be a real problem.  Mailing lists are
> going to have to evolve how they send or something.

p=reject is fine, but missing dkim on that policy is not working

i still have to see docs on why this is not supported at all

https://dmarc.org/2017/03/can-i-use-dmarc-if-i-have-only-deployed-spf/

good page that does not help much on how to configure dmarc to not
reject maillists even for domain with policy reject
Reply | Threaded
Open this post in threaded view
|

Re: Somewhat OT: DMARC and this list

Benny Pedersen-2
In reply to this post by Alan Hodgson
Alan Hodgson skrev den 2017-05-19 22:34:

> Well, it's not the list. Others' signatures are coming through fine.

problem is that dkim is not showing to apache.org mailserver, so
downstream testing dmarc rejects, undesired config in many ways

> I had to tell OpenDMARC to whitelist ena.com to get anything from you.

i have to allow all sender in postfix to allow junc.eu to send forged
mails to me, same as i need to use whitelist_from *@junc.eu to ensure my
own postting to maillist not jump in the junk folder :=)

in opendmarc you should not whitelist mfrom domains with reject, but
more whitelist maillists ips, but i have hoped this would be more simple
to make work stable ?

but whitelist based on ip, disable dmarc pass testing :/

if there would be a public change to dmarc, it would be nice to see if
arc is ever needed, if dkim was never breaked all parts of dmarc and arc
is unneeded in everyday work

i still find it ironical that dmarc maillists breaks dkim, or even take
ownerships on mfrom, yark
Reply | Threaded
Open this post in threaded view
|

Re: Somewhat OT: DMARC and this list

David B Funk
In reply to this post by David Jones
On Fri, 19 May 2017, David Jones wrote:

>> From: David B Funk <[hidden email]>
>  
>> On Fri, 19 May 2017, RW wrote:
>
>>> On Fri, 19 May 2017 14:13:22 -0500 (CDT)
>>> David B Funk wrote:
>>>
>>> ne.
>>>>
>>>> My read on this is that "@ena.com" is living dangerously. They
>>>> publish SPF records and DMARC records (with p=reject) but do NOT DKIM
>>>> sign their mail.
>>>
>>> Most of them pass DKIM, a minority aren't signed.
>
>> Urgg, I see that now. I looked at a few of David Jones' posts to this list and
>> saw that they weren't DKIM signed, so I extrapolated that to a general
>> asumption.
>
> They are DKIM signed so something must be striping the headers.
>
>> I see that they're using Office-365. This is one of the issues I have with
>> 0-365, it's a black box which is hard to second guess.
>> Sometimes they DKIM sign, some times they don't.
>> Sometimes they will score incoming messasge that are properly DKIM signed as
>> spam (for no reason other than the DKIM signature, as far as I can tell).
>
>> Bottom line; If you put yourself at the mercy of Office-365, using a DKIM policy
>> of "reject" is risky.
>
> I don't.  Our inbound to and outbound from Office 365 is handled by our
> own mail servers that are properly DKIM signing.  I have been reviewing
> DMARC reports for years now to make sure we had good SPF, DKIM and
> DMARC before recently moving to p=reject.
>
> Dave
I hate to break it to you but you are at the mercy of Office-365 and its erratic
DKIM policy.

The message from you that I'm replying to here (both the one that came directly
to me and the copy I got thru the  Apache list server) are -totally- devoid of
DKIM headers. (If you'd like to see it I can put it up in paste-bin.)

Looking at some of your other posts to this list, many of them do have DKIM
headers but not all. The interesting part is that the DKIM headers are
interpolated with the O-365 headers so it looks like O-365 is taking your
original message, stripping off the DKIM headers and sometimes re-adding them.

Good luck with this, welcome to the O-365 world.

Dave

--
Dave Funk                                  University of Iowa
<dbfunk (at) engineering.uiowa.edu>        College of Engineering
319/335-5751   FAX: 319/384-0549           1256 Seamans Center
Sys_admin/Postmaster/cell_admin            Iowa City, IA 52242-1527
#include <std_disclaimer.h>
Better is not better, 'standard' is better. B{
Reply | Threaded
Open this post in threaded view
|

Re: Somewhat OT: DMARC and this list

RW-15
In reply to this post by Benny Pedersen-2
On Fri, 19 May 2017 22:40:41 +0200
Benny Pedersen wrote:


> problem with rfcs for dmarc is that its not possible to whitelist
> maillists servers so thay never reject on policy reject, what would
> happend if we all reject on a single domain that have policy
> reject ?, then no one would be subscripbed at the end, if one like to
> follow own rules on reject
>
> it would be nice if dmarc could handle reject policy better if spf
> passed, maybe lua scripted ?

There is a better solution:

 http://arc-spec.org/.
Reply | Threaded
Open this post in threaded view
|

Re: Somewhat OT: DMARC and this list

David Jones
In reply to this post by David B Funk
>From: David B Funk <[hidden email]>
   
>On Fri, 19 May 2017, David Jones wrote:

>>> From: David B Funk <[hidden email]>
>>  
>>> On Fri, 19 May 2017, RW wrote:
>>
>>>> On Fri, 19 May 2017 14:13:22 -0500 (CDT)
>>>> David B Funk wrote:
>>>>
>>>> ne.
>>>>>
>>>>> My read on this is that "@ena.com" is living dangerously. They
>>>>> publish SPF records and DMARC records (with p=reject) but do NOT DKIM
>>>>> sign their mail.
>>>>
>>>> Most of them pass DKIM, a minority aren't signed.
>>
>>> Urgg, I see that now. I looked at a few of David Jones' posts to this list and
>>> saw that they weren't DKIM signed, so I extrapolated that to a general
>>> asumption.
>>
>> They are DKIM signed so something must be striping the headers.
>>
>>> I see that they're using Office-365. This is one of the issues I have with
>>> 0-365, it's a black box which is hard to second guess.
>>> Sometimes they DKIM sign, some times they don't.
>>> Sometimes they will score incoming messasge that are properly DKIM signed as
>>> spam (for no reason other than the DKIM signature, as far as I can tell).
>>
>>> Bottom line; If you put yourself at the mercy of Office-365, using a DKIM policy
>>> of "reject" is risky.
>>
>> I don't.  Our inbound to and outbound from Office 365 is handled by our
>> own mail servers that are properly DKIM signing.  I have been reviewing
>> DMARC reports for years now to make sure we had good SPF, DKIM and
>> DMARC before recently moving to p=reject.
>>
>> Dave

>I hate to break it to you but you are at the mercy of Office-365 and its erratic
>DKIM policy.

>The message from you that I'm replying to here (both the one that came directly
>to me and the copy I got thru the  Apache list server) are -totally- devoid of
>DKIM headers. (If you'd like to see it I can put it up in paste-bin.)

I figured out what was going on.  Microsoft must have recently (past few
months or so) started sending our outbound mail through another IP range.
I have updated my opendkim.conf to cover all Office 365 outbound servers.

Dave
Reply | Threaded
Open this post in threaded view
|

Re: Somewhat OT: DMARC and this list

David B Funk
On Sat, 20 May 2017, David Jones wrote:

>> From: David B Funk <[hidden email]>
[snip..]
>> The message from you that I'm replying to here (both the one that came directly
>> to me and the copy I got thru the  Apache list server) are -totally- devoid of
>> DKIM headers. (If you'd like to see it I can put it up in paste-bin.)
>
> I figured out what was going on.  Microsoft must have recently (past few
> months or so) started sending our outbound mail through another IP range.
> I have updated my opendkim.conf to cover all Office 365 outbound servers.

This is one of the things that I dislike/fear about being dependent on
cloud based services.
Many traditional system paradigms use the concept of trusted IP
addresses (EG: internal_networks, trusted_networks, etc) for making
operational decisions.

When using cloud based services you have no control over their IP
addresses and have to worry about when they might change with out notice,
whom else they might be servicing using those same addrs, AND when they
might abandon them only for somebody else to start using them.

It also reduces the usefulness of RBLS and can even adversely affect the
performance of things such as Bayes.

When you get major amounts of Ham from O-365 most of the tokens derived
from O-365 messages get 0.000 score. So when spammers use O-365 even
blatant spam gets a Bayes score of 00%. (and this is after putting all the
O-365 headers in bayes_ignore_header statements).
(Our institution recently moved the majority of users' mail to O-365 so
this is a battle I'm fighting now).

Bottom line, in this brave new world address based auth(n/z) decisions are
going to be increasingly problematic and an increasing reliance on things
such as digital signatures.

Dave

--
Dave Funk                                  University of Iowa
<dbfunk (at) engineering.uiowa.edu>        College of Engineering
319/335-5751   FAX: 319/384-0549           1256 Seamans Center
Sys_admin/Postmaster/cell_admin            Iowa City, IA 52242-1527
#include <std_disclaimer.h>
Better is not better, 'standard' is better. B{
12