DMARC reports after emails sent to list

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

DMARC reports after emails sent to list

Andrew McGlashan
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi,

I have DMARC with DKIM and SPF setup for my domain name.

When I sent emails to Debian lists, I tend to get a bunch of DMARC
reports as a result.  The reports of concern are ones that show a
sending IP for my domain that is the IP of the Debian mail server for
the list.

Is this due to email forwarding by Debian servers or is it for some
other reason? How can I fix this?

Do I need to add Debian's IP address to my SPF record?  I'm not sure I
want to, but it may end the DMARC reports with failed SPF tests...



Here is the output from a report:

$ zcat
noloop.tana.it\!affinityvision.com.au\!1570838400\!1570924800\!e4b6e7354
eab4dd19d4c5016fd8a34e2.xml.gz

<?xml version="1.0" encoding="UTF-8" ?>
<feedback>
        <report_metadata>
                <org_name>tana.it</org_name>
                <email>[hidden email]</email>
                <report_id>e4b6e7354eab4dd19d4c5016fd8a34e2</report_id>
                <date_range>
                        <begin>1570838400</begin>
                        <end>1570924800</end>
                </date_range>
        </report_metadata>
        <policy_published>
                <domain>affinityvision.com.au</domain>
                <adkim>s</adkim>
                <aspf>s</aspf>
                <p>quarantine</p>
                <sp>none</sp>
        </policy_published>
        <record>
                <row>
                        <source_ip>82.195.75.100</source_ip>
                        <count>1</count>
                        <policy_evaluated>
                                <disposition>none</disposition>
                                <dkim>pass</dkim>
                                <spf>fail</spf>
                        </policy_evaluated>
                </row>
                <identifiers>
                        <header_from>affinityvision.com.au</header_from>
                </identifiers>
                <auth_results>
                        <dkim>
                                <domain>affinityvision.com.au</domain>
                                <selector>2018061201</selector>
                                <result>pass</result>
                        </dkim>
                        <spf>
                                <domain>lists.debian.org</domain>
                                <result>permerror</result>
                                <scope>mfrom</scope>
                        </spf>
                </auth_results>
        </record>
</feedback>


Thanks and Kind Regards
AndrewM
-----BEGIN PGP SIGNATURE-----

iHUEAREIAB0WIQTJAoMHtC6YydLfjUOoFmvLt+/i+wUCXaK0CgAKCRCoFmvLt+/i
+0oLAQDVneyJiLw6C9SM4DDCpNTejcIYlyYV3nLkUY3g714q4wD/al7A+fGiON6J
oCgMSMPrAg4ykZYhLcg2UIMDbaWv92Y=
=tUMU
-----END PGP SIGNATURE-----

Reply | Threaded
Open this post in threaded view
|

Re: DMARC reports after emails sent to list

Reco
        Hi.

On Sun, Oct 13, 2019 at 04:20:17PM +1100, Andrew McGlashan wrote:
> Is this due to email forwarding by Debian servers or is it for some
> other reason? How can I fix this?

bendel.debian.org (the MTA behind lists.debian.org) does not have a
published SPF record. An MTA, tana.it in this case, which is configured
in a paranoid way (every inbound e-mail must conform to a published SPF
record) - will consider every e-mail from bendel.debian.org as a
violation.
It's not just you - I too receive DMARC reports from tana.it at the end
of every day which I communicate to the list, and a couple of others
attempt to send me DMARC reports too (but I see no reason to accept
connection from China Telecom MTAs).
It's not that bad, we're talking about extra 5-10 e-mails per day if you
don't do any filtering.


> Do I need to add Debian's IP address to my SPF record?  I'm not sure I
> want to, but it may end the DMARC reports with failed SPF tests...

I don't see how it'll do you any good. SPF checking for a maillist mail
has little to no meaning anyway, it's tana.it who should fix their SPF
checks.

I'd send a mail to [hidden email], IIRC one of this list
members is behind it.

Reco

Reply | Threaded
Open this post in threaded view
|

Re: DMARC reports after emails sent to list

Andrew McGlashan
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi,

Thanks Reco.

On 13/10/19 9:59 pm, Reco wrote:

> On Sun, Oct 13, 2019 at 04:20:17PM +1100, Andrew McGlashan wrote:
>> Is this due to email forwarding by Debian servers or is it for
>> some other reason? How can I fix this?
>
> bendel.debian.org (the MTA behind lists.debian.org) does not have
> a published SPF record. An MTA, tana.it in this case, which is
> configured in a paranoid way (every inbound e-mail must conform to
> a published SPF record) - will consider every e-mail from
> bendel.debian.org as a violation. It's not just you - I too receive
> DMARC reports from tana.it at the end of every day which I
> communicate to the list, and a couple of others attempt to send me
> DMARC reports too (but I see no reason to accept connection from
> China Telecom MTAs). It's not that bad, we're talking about extra
> 5-10 e-mails per day if you don't do any filtering.
>
>> Do I need to add Debian's IP address to my SPF record?  I'm not
>> sure I want to, but it may end the DMARC reports with failed SPF
>> tests...
>
> I don't see how it'll do you any good. SPF checking for a maillist
> mail has little to no meaning anyway, it's tana.it who should fix
> their SPF checks.
>
> I'd send a mail to [hidden email], IIRC one of this
> list members is behind it.

Hopefullly:  "Alessandro Vesely <[hidden email]>" can see this thread ;-
)

And yes, you are right, it passes DKIM fine and gives SPF error due to
the MTA as you say.  Probably the same with other reports as well.

Cheers
A.
-----BEGIN PGP SIGNATURE-----

iHUEAREIAB0WIQTJAoMHtC6YydLfjUOoFmvLt+/i+wUCXaMUDwAKCRCoFmvLt+/i
+/2dAQCtYbPOkTl5vER4z9a5X6ox0L/eMtM9A3Uda30Od/BkdgEAsvwR9eHJSUPF
kP1TAssbm3YLc6yXX1DYXVGhs4Ii5pc=
=d1Id
-----END PGP SIGNATURE-----

Reply | Threaded
Open this post in threaded view
|

Re: DMARC reports after emails sent to list

황병희-3
In reply to this post by Andrew McGlashan
Hellow Andrew!!!

Andrew McGlashan <[hidden email]> writes:

> Hi,
>
> I have DMARC with DKIM and SPF setup for my domain name.

There was related discussion: it's very seriosus...
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=754809

>
> When I sent emails to Debian lists, I tend to get a bunch of DMARC
> reports as a result.  The reports of concern are ones that show a
> sending IP for my domain that is the IP of the Debian mail server for
> the list.
>
> Is this due to email forwarding by Debian servers or is it for some
> other reason? How can I fix this?
>
> Do I need to add Debian's IP address to my SPF record?  I'm not sure I
> want to, but it may end the DMARC reports with failed SPF tests...
>
>
>
> Here is the output from a report:
>
> $ zcat
> noloop.tana.it\!affinityvision.com.au\!1570838400\!1570924800\!e4b6e7354
> eab4dd19d4c5016fd8a34e2.xml.gz
>
> <?xml version="1.0" encoding="UTF-8" ?>
> <feedback>
> <report_metadata>
> <org_name>tana.it</org_name>
> <email>[hidden email]</email>
> <report_id>e4b6e7354eab4dd19d4c5016fd8a34e2</report_id>
> <date_range>
> <begin>1570838400</begin>
> <end>1570924800</end>
> </date_range>
> </report_metadata>
> <policy_published>
> <domain>affinityvision.com.au</domain>
> <adkim>s</adkim>
> <aspf>s</aspf>
> <p>quarantine</p>
> <sp>none</sp>
> </policy_published>
> <record>
> <row>
> <source_ip>82.195.75.100</source_ip>
> <count>1</count>
> <policy_evaluated>
> <disposition>none</disposition>
> <dkim>pass</dkim>
> <spf>fail</spf>
> </policy_evaluated>
> </row>
> <identifiers>
> <header_from>affinityvision.com.au</header_from>
> </identifiers>
> <auth_results>
> <dkim>
> <domain>affinityvision.com.au</domain>
> <selector>2018061201</selector>
> <result>pass</result>
> </dkim>
> <spf>
> <domain>lists.debian.org</domain>
> <result>permerror</result>
> <scope>mfrom</scope>
> </spf>
> </auth_results>
> </record>
> </feedback>
>
>
> Thanks and Kind Regards
> AndrewM

Sincerely,

--
^고맙습니다 _地平天成_ 감사합니다_^))//

Reply | Threaded
Open this post in threaded view
|

Re: DMARC reports after emails sent to list

Andrew McGlashan
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi,

On 14/10/19 9:42 pm, 황병희 wrote:
> Andrew McGlashan <[hidden email]> writes:
>> I have DMARC with DKIM and SPF setup for my domain name.
>
> There was related discussion: it's very seriosus...
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=754809

Okay, well, I have p=quarantine for my setup, not p=reject, but that
doesn't seem to be enough.

I get reports from all over the place; the SPF failures may well be
due to the list emails not having an SPF policy and I'm not going to
give credentials to Debian to sent emails as me from my server for the
list as that would be a security risk that is too great.

DMARC needs to work, not be broken at all; it is supposed to help with
legitimate mail delivery, not hinder it.

SPF should be checked properly as well and emails rejected when they
don't comply with the domain name's specified "rules".  So many domain
names have multiple SPF records (which results in permerror as you can
only have one SPF record).  It's not as if SPF is new, it has been a
thing for quite long enough to treat it's rules appropriately.  It
also annoys me when people use "~all" .... to me that simply means,
"screw it, we don't really care or we don't have a clue how to make
this work"; it should be "-all" only, unless you are in a testing
phase and are not yet committed to using SPF properly.  Of course
using "~all" will help when servers don't otherwise play ball
correctly, but it's still very wrong to me.

It might be better if real mail servers could freely register
themselves as proper mail servers, they get a signed assertion to use
from some shared authority, everyone should register and then the
spammers and fraudsters should be left out in the cold.  It would be
important that legitimate servers be able to fix problems easily
without extorting funds from them to fix things.  If you run a mail
server, your reputation is at stake, and your rep should count for
something; if you abuse your assertion, then you should be subject to
losing it.

Sure, there will be errors with setups as humans are involved; those
should be found and fixed, then properly observed.

There is another level of problems when emails are forwarded on to the
rotten mass public mail services; ordinary forwarding brings all sorts
of other problems (forward as attachment mitigates these problems, but
it is less easy unless manually done from client email program).

I can blacklist bad IP address of mail servers that are found to be
doing the wrong thing (just like RBLs do), but I can't block out a
whole bunch of providers that allow their users to send spam through
them, such as Microsoft, Google, Yahoo and even Apple and that's
before even thinking about sendgrid, mandrill and other mass mailing
services -- we can't easily stop rubbish from those servers without
blocking good users whom use those services.  It would be so much
better if the big guys would shut up shop or otherwise crack down on
bad users and stop the problems that require SPF, DMARC and the like.

Kind Regards
AndrewM

-----BEGIN PGP SIGNATURE-----

iHUEAREIAB0WIQTJAoMHtC6YydLfjUOoFmvLt+/i+wUCXaSAXQAKCRCoFmvLt+/i
+8lOAQCqdnAqBakq35H+Sz9ufUY4wlnWOwwqYIDMdlQo+jZVtgD/TiosMfHf2DUv
KDvegBieGl9Z3d2O2w0gVj2UFvd/8q4=
=zBfJ
-----END PGP SIGNATURE-----

Reply | Threaded
Open this post in threaded view
|

Re: DMARC reports after emails sent to list

Nicholas Geovanis-2
On Mon, Oct 14, 2019 at 9:04 AM Andrew McGlashan <[hidden email]> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
.... 
-- we can't easily stop rubbish from those servers without
blocking good users whom use those services.  It would be so much
better if the big guys would shut up shop or otherwise crack down on
bad users and stop the problems that require SPF, DMARC and the like.

My fearful expectation is that "the big guys" will soon be a very short list, headed
up by AWS and Google Cloud. I haven't done AWS work in a couple of years now
but memory says that proper SPF was required to transit their infrastructure.
 
Kind Regards
AndrewM

-----BEGIN PGP SIGNATURE-----

iHUEAREIAB0WIQTJAoMHtC6YydLfjUOoFmvLt+/i+wUCXaSAXQAKCRCoFmvLt+/i
+8lOAQCqdnAqBakq35H+Sz9ufUY4wlnWOwwqYIDMdlQo+jZVtgD/TiosMfHf2DUv
KDvegBieGl9Z3d2O2w0gVj2UFvd/8q4=
=zBfJ
-----END PGP SIGNATURE-----
Reply | Threaded
Open this post in threaded view
|

Re: DMARC reports after emails sent to list

Alessandro Vesely
In reply to this post by Andrew McGlashan
Hi,

On 13/10/2019 14:09, Andrew McGlashan wrote:
> Hi,
>
> Thanks Reco.
>
> On 13/10/19 9:59 pm, Reco wrote:
> [...]
>
>> I'd send a mail to [hidden email], IIRC one of this
>> list members is behind it.


Didn't get it


> Hopefullly:  "Alessandro Vesely <[hidden email]>" can see this thread ;-)


Yes, I can...


Best
Ale


signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: DMARC reports after emails sent to list

Alessandro Vesely
In reply to this post by Andrew McGlashan
Hi again,

On 14/10/2019 16:04, Andrew McGlashan wrote:

> Hi,
>
> On 14/10/19 9:42 pm, 황병희 wrote:
>> Andrew McGlashan <[hidden email]> writes:
>
>> There was related discussion: it's very seriosus...
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=754809
>
> Okay, well, I have p=quarantine for my setup, not p=reject, but that
> doesn't seem to be enough.

A notification that SPF failed says nothing about delivery.


> I get reports from all over the place; the SPF failures may well be
> due to the list emails not having an SPF policy and I'm not going to
> give credentials to Debian to sent emails as me from my server for the
> list as that would be a security risk that is too great.


SPF is (not) verified against helo=bendel.debian.org and mfrom=lists.debian.org

Then the report is sent to you because of the From: address.


> DMARC needs to work, not be broken at all; it is supposed to help with
> legitimate mail delivery, not hinder it.


Yes, that's what reports supposedly do.  They tell you how your DMARC
authentication goes.  In theory, you should be able to decide how to set your
policy based on them...


> SPF should be checked properly as well and emails rejected when they
> don't comply with the domain name's specified "rules".


Right.


> So many domain names have multiple SPF records (which results in permerror
> as you can only have one SPF record).

Debian has no SPF record.  My MTA reports "unknown", which gets translated to
permerror, possibly not perfectly well.


>  It's not as if SPF is new, it has been a
> thing for quite long enough to treat it's rules appropriately.  It
> also annoys me when people use "~all" .... to me that simply means,
> "screw it, we don't really care or we don't have a clue how to make
> this work"; it should be "-all" only, unless you are in a testing
> phase and are not yet committed to using SPF properly.  Of course
> using "~all" will help when servers don't otherwise play ball
> correctly, but it's still very wrong to me.


Agreed.


> It might be better if real mail servers could freely register
> themselves as proper mail servers, they get a signed assertion to use
> from some shared authority, everyone should register and then the
> spammers and fraudsters should be left out in the cold.


There are whitelists, e.g. dnswl.org...


> It would be important that legitimate servers be able to fix problems
> easily without extorting funds from them to fix things.  If you run a mail
> server, your reputation is at stake, and your rep should count for
> something; if you abuse your assertion, then you should be subject to losing
> it.

A failed SPF authentication doesn't mine reputation.


> Sure, there will be errors with setups as humans are involved; those
> should be found and fixed, then properly observed.
>
> There is another level of problems when emails are forwarded on to the
> rotten mass public mail services; ordinary forwarding brings all sorts
> of other problems (forward as attachment mitigates these problems, but
> it is less easy unless manually done from client email program).


Appendix D.3 of [RFC7208] is the best cure I found.


> I can blacklist bad IP address of mail servers that are found to be
> doing the wrong thing (just like RBLs do), but I can't block out a
> whole bunch of providers that allow their users to send spam through
> them, such as Microsoft, Google, Yahoo and even Apple and that's
> before even thinking about sendgrid, mandrill and other mass mailing
> services -- we can't easily stop rubbish from those servers without
> blocking good users whom use those services.  It would be so much
> better if the big guys would shut up shop or otherwise crack down on
> bad users and stop the problems that require SPF, DMARC and the like.


Email authentication is an attempt at discerning mail flows.  Being
authenticated doesn't imply good or bad.  DMARC added feedback, which should be
useful.  Personally, I check DMARC reports (their XSLT htmlized version) after
rotating DKIM keys, and in some other rather uncommon circumstances.  Some
people pile them up in a database and run queries on it.  Others outsource
their interpretation.  They are strictly OPT-IN, so if you don't want them you
can just not ask for them.


Best
Ale


signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: DMARC reports after emails sent to list

황병희-3
In reply to this post by Andrew McGlashan
Helow Andrew,

Andrew McGlashan <[hidden email]> writes:

> Hi,
>
> On 14/10/19 9:42 pm, 황병희 wrote:
>> Andrew McGlashan <[hidden email]> writes:
>>> I have DMARC with DKIM and SPF setup for my domain name.
>>
>> There was related discussion: it's very seriosus...
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=754809
>
> Okay, well, I have p=quarantine for my setup, not p=reject, but that
> doesn't seem to be enough.
>
> I get reports from all over the place; the SPF failures may well be
> due to the list emails not having an SPF policy and I'm not going to
> give credentials to Debian to sent emails as me from my server for the
> list as that would be a security risk that is too great.
>
> DMARC needs to work, not be broken at all; it is supposed to help with
> legitimate mail delivery, not hinder it.
>
> SPF should be checked properly as well and emails rejected when they
> don't comply with the domain name's specified "rules".  So many domain
> names have multiple SPF records (which results in permerror as you can
> only have one SPF record).  It's not as if SPF is new, it has been a
> thing for quite long enough to treat it's rules appropriately.  It
> also annoys me when people use "~all" .... to me that simply means,
> "screw it, we don't really care or we don't have a clue how to make
> this work"; it should be "-all" only, unless you are in a testing
> phase and are not yet committed to using SPF properly.  Of course
> using "~all" will help when servers don't otherwise play ball
> correctly, but it's still very wrong to me.
>
> It might be better if real mail servers could freely register
> themselves as proper mail servers, they get a signed assertion to use
> from some shared authority, everyone should register and then the
> spammers and fraudsters should be left out in the cold.  It would be
> important that legitimate servers be able to fix problems easily
> without extorting funds from them to fix things.  If you run a mail
> server, your reputation is at stake, and your rep should count for
> something; if you abuse your assertion, then you should be subject to
> losing it.
>
> Sure, there will be errors with setups as humans are involved; those
> should be found and fixed, then properly observed.
>
> There is another level of problems when emails are forwarded on to the
> rotten mass public mail services; ordinary forwarding brings all sorts
> of other problems (forward as attachment mitigates these problems, but
> it is less easy unless manually done from client email program).
>
> I can blacklist bad IP address of mail servers that are found to be
> doing the wrong thing (just like RBLs do), but I can't block out a
> whole bunch of providers that allow their users to send spam through
> them, such as Microsoft, Google, Yahoo and even Apple and that's
> before even thinking about sendgrid, mandrill and other mass mailing
> services -- we can't easily stop rubbish from those servers without
> blocking good users whom use those services.  It would be so much
> better if the big guys would shut up shop or otherwise crack down on
> bad users and stop the problems that require SPF, DMARC and the like.

Please, i'm using sometimes Amazon SES as outbond, so forgive me
i'm not spammer,, Anyway thanks for long comments!!!

> Kind Regards
> AndrewM
>

Sincerely,

--
^고맙습니다 _地平天成_ 감사합니다_^))//