Gmail and spam, a request

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

Re: Gmail and spam, a request

Juri Haberland
On 26/04/2020 13:21, Francesc Peñalvez wrote:
> I don't have the correct dkim entry in the domain?

In this post you have no dkim signature at all!


  Juri
Reply | Threaded
Open this post in threaded view
|

Re: Gmail and spam, a request

Wietse Venema
Juri Haberland:
> On 26/04/2020 13:21, Francesc Pe?alvez wrote:
> > I don't have the correct dkim entry in the domain?
>
> In this post you have no dkim signature at all!

Confirmed. Your message has no DKIM related headers at all.
That would explain why only SPF is in effect.

        Wietse

Received: from ns.almogavers.net (static-213-57-26-46.ipcom.comunitel.net [46.26.57.213])
        (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
        (No client certificate requested)
        by english-breakfast.cloud9.net (Postfix) with ESMTPS id 2B952336820
        for <[hidden email]>; Sun, 26 Apr 2020 07:21:53 -0400 (EDT)
Received: from ns.almogavers.net (localhost [127.0.0.1])
        by ns.almogavers.net (Postfix) with ESMTP id BA0357E123C
        for <[hidden email]>; Sun, 26 Apr 2020 13:21:51 +0200 (CEST)
Received: by ns.almogavers.net (Postfix, from userid 5555)
        id 506067E14EF; Sun, 26 Apr 2020 13:21:51 +0200 (CEST)
X-Spam-Level:
X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on ns.almogavers.net
X-Spam-Status: No, score=-84.5 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_99,
        BAYES_999,DCC_REPUT_00_12,DKIM_ADSP_ALL,DMARC_REJECT,URIBL_BLOCKED,
        USER_IN_WHITELIST autolearn=no autolearn_force=no version=3.4.2
Received: from [192.168.0.4] (win.almogavers.net [192.168.0.4])
        (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
         key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
        (Client did not present a certificate)
        (Authenticated sender: [hidden email])
        by ns.almogavers.net (Postfix) with ESMTPSA id 276F67E123C
        for <[hidden email]>; Sun, 26 Apr 2020 13:21:44 +0200 (CEST)
Subject: Re: Gmail and spam, a request
To: [hidden email]
References: <[hidden email]>
 <[hidden email]>
 <[hidden email]>
 <[hidden email]>
 <[hidden email]>
 <[hidden email]>
 <[hidden email]>
 <[hidden email]>
 <[hidden email]>
 <[hidden email]>
From: =?UTF-8?Q?Francesc_Pe=c3=b1alvez?= <[hidden email]>
Organization: Almogavers SAU
Message-ID: <[hidden email]>
Date: Sun, 26 Apr 2020 13:21:43 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:76.0) Gecko/20100101
 Thunderbird/76.0
MIME-Version: 1.0
In-Reply-To: <[hidden email]>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: es-ES
X-AV-Checked: ClamAV using ClamSMTP
Sender: [hidden email]
Precedence: bulk
List-Id: Postfix users <[hidden email]>
List-Post: <mailto:[hidden email]>
List-Help: <http://www.postfix.org/lists.html>
List-Unsubscribe: <mailto:[hidden email]>
List-Subscribe: <mailto:[hidden email]>
Status: RO
Content-Length: 919
Lines: 28
Reply | Threaded
Open this post in threaded view
|

Re: Gmail and spam, a request

Richard Damon
In reply to this post by Jaroslaw Rafa
On 4/26/20 3:23 PM, Jaroslaw Rafa wrote:

> Dnia 26.04.2020 o godz. 08:00:56 Richard Damon pisze:
>> This is exactly what DMARC is intended to indicate. Configuring a domain
>> with DMARC says that it is intended that message only be accepted if
>> they come directly from the sender. It was designed for things like
>> Banks to be able to send out messages that the recipients can trust came
>> from them and not a scammer.
> But email providers like Google are ignoring the fact that DMARC was
> intended for such purposes, and consider it an universal anti-spam measure.
> Google, as a recipient, clearly indicates in their sender guidelines
> (targeted at senders who have trouble with deliverability of their messages
> to Gmail users - among other cases, messages being placed in Spam folder)
> that the sender has to have DMARC, DKIM and SPF configured. That's the first
> thing they require from you if you have any deliverability problems with
> them. However, having all this set up doesn't provide any guarantee that
> your email won't be qualified as spam (so why require it at all?).
> BTW, with regard to messages being marked spam, DMARC reports are pretty
> useless because they don't give you any information about that. And that
> would be actually the most interesting thing in those reports. They only
> give me information whether the message passed or failed DMARC/DKIM/SPF
> check, but this tells me nothing in terms of knowing if the recipient
> actually got my message or not.
> What's worse, Gmail does not honor Disposition-Notification-To: header,
> which could be used to determine if the recipienta ctually read my message
> or not.
> So sending mail to someone at Gmail is actually sending it into the
> unknown...

I have never had GMail ask me to setup DMARC, they will ask you to setup
SPF or DKIM as a first step for delivery problems, as letting them
confirm SENDER (not From) is the first step to them being able to do
something about you. With SPF enabled, then they can verify that any
message that claims you are the sender of the message, is actually
coming from a machine under you control, so they can reject forged senders.

Note, there is a MAJOR difference between SPF and DKIM as stand alone
protocols, and on how they are used within DMARC. Plain SPF/DKIM are
tied to the sender of the message, which should be a reference to the
machine that actually sending the message (or the organizations that
control it). For instance, all messages from this mailing list have a
sender address that is in the postfix.org domain. If a machine receives
a message, and then sends it along anew (like a mailing list) then it is
supposed to reset the sender to itself (as that is where deliver errors
should go) in the process. That means that messages from this list will
be checked against the postfix.org SPF and DKIM rules, so it can
validate that this transmission was initiated by something at postfix.org

When DMARC comes into play, rather than using the sender, you check the
From: header, which a re-sender is NOT supposed to change. This means
that messages from this list are likely going to fail DMARC/SPF, unless
the domain that originated the message specifically added the
postfix.org outgoing email servers to its allowed host list. (and ARC
when it is working might allow that domain to say that it trust
postfix.org to verify and re-transmit its messages). IF the originating
server has a properly configured DMARC/DKIM setup, then the message will
be signed, and because the postfix.org mailing lists don't touch the
parts of the message normally signed by DKIM, the relayed message will
pass DMARC/DKIM and thus pass DMARC (since only one needs to pass). More
commonly, many email list systems will do minor administrative changes
to the message (adding a subject wart or a list footer) which will break
DKIM and thus the fail DMARC/DKIM abd DMARC/SPF.

GMail isn't really out of line in using broken DMARC as a spam
indicator. Domains with DMARC enabled have indicated that they what
people to be careful about their messages, and broken DMARC is a sign of
problems. It could be argued that if the DMARC uses p=none then it
shouldn't count against delivery, but by a reasonable interpretation of
the RFC, delivery to the GMail spam folder does qualify as delivery, and
there aren't any hard rules about spam detection.

Yes, DMARC replies won't let you know if the user every actually saw the
message, that isn't there purpose. There purpose is to help you know how
bad your spoofing problem is, or to help you diagnose your own outgoing
DMARC issues.

As to Disposition-Notification-To: headers, the RFC for those clearly
state that it is just a polite request to the receiving system, and they
are well within bounds to ignore it. I personally always disable the
automatic reply off those headers (and won't use a system that won't let
me do so if I have any choice about it).

--
Richard Damon

Reply | Threaded
Open this post in threaded view
|

Re: Gmail and spam, a request

Jaroslaw Rafa
Dnia 26.04.2020 o godz. 17:00:31 Richard Damon pisze:
>
> I have never had GMail ask me to setup DMARC, they will ask you to setup
> SPF or DKIM as a first step for delivery problems, as letting them

Did you read https://support.google.com/mail/answer/81126 ? (That's the page
their "sender troubleshooter" form is referring to)

"To minimize the chance that your messages are marked as spam, set up these
authentication methods:

*    Publish an SPF record for your domain. SPF prevents spammers from
sending unauthorized messages that appear to be from your domain.
*    Turn on DKIM signing for your messages. Receiving servers use DKIM to
verify that the domain owner actually sent the message. Important: Gmail
requires a DKIM key of 1024 bits or longer.
*    Publish a DMARC record for your domain. DMARC helps senders protect
their domain against email spoofing."

When you fill in the sender troubleshooter form, it asks you explicitly if
you have done all this.

> As to Disposition-Notification-To: headers, the RFC for those clearly
> state that it is just a polite request to the receiving system, and they
> are well within bounds to ignore it. I personally always disable the
> automatic reply off those headers (and won't use a system that won't let
> me do so if I have any choice about it).

With Gmail - at least with Gmail's web interface (and that's what the
majority of their users use) - you have no choice. It simply doesn't support
that header at all.
--
Regards,
   Jaroslaw Rafa
   [hidden email]
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."
Reply | Threaded
Open this post in threaded view
|

Re: Gmail and spam, a request

Richard Damon
On 4/26/20 6:41 PM, Jaroslaw Rafa wrote:
> Dnia 26.04.2020 o godz. 17:00:31 Richard Damon pisze:
>> I have never had GMail ask me to setup DMARC, they will ask you to setup
>> SPF or DKIM as a first step for delivery problems, as letting them
> Did you read https://support.google.com/mail/answer/81126 ? (That's the page
> their "sender troubleshooter" form is referring to)

That looks like it got added since the last time I needed to deal with
them, just having SPF has done well enough for most of my needs. My
major issue has been running a mailing list, so most of my outgoing mail
doesn't have my domain in it so DMARC isn't as important for my domain.

> "To minimize the chance that your messages are marked as spam, set up these
> authentication methods:
>
> *    Publish an SPF record for your domain. SPF prevents spammers from
> sending unauthorized messages that appear to be from your domain.
> *    Turn on DKIM signing for your messages. Receiving servers use DKIM to
> verify that the domain owner actually sent the message. Important: Gmail
> requires a DKIM key of 1024 bits or longer.
> *    Publish a DMARC record for your domain. DMARC helps senders protect
> their domain against email spoofing."
>
> When you fill in the sender troubleshooter form, it asks you explicitly if
> you have done all this.
>
>> As to Disposition-Notification-To: headers, the RFC for those clearly
>> state that it is just a polite request to the receiving system, and they
>> are well within bounds to ignore it. I personally always disable the
>> automatic reply off those headers (and won't use a system that won't let
>> me do so if I have any choice about it).
> With Gmail - at least with Gmail's web interface (and that's what the
> majority of their users use) - you have no choice. It simply doesn't support
> that header at all.

In my opinion, totally ignoring the header is not that bad of an option.

--
Richard Damon

Reply | Threaded
Open this post in threaded view
|

Re: Gmail and spam, a request

Peter Ajamian
In reply to this post by Ralph Seichter-2
On 27/04/20 1:16 am, Ralph Seichter wrote:

> * [hidden email]:
>
>> People may configure strict DMARC policies for various different
>> reasons, may be unaware of the issues that causes and may not even
>> have control over the domain at all.
>
> Lack of knowledge is not an excuse, period. Lack of control just means
> the domain's admin needs to poke somebody up the administrative chain to
> do their job. In any case, it ist not something the Postfix mailing list
> must deal with, because it already -- and wisely -- does not add subject
> prefixes or message footers, meaning DKIM signatures remain intact. Any
> admin who uses DMARC while not having set up DKIM correctly is asking
> for trouble. I won't lift a finger to work around the incompetence of
> others in this case, nor do I think this list's manager should.
>
> To aspiring admins out there: Running MTAs requires some skill. You can
> do it, but you don't have to. If you decide to go ahead but are doing
> things wrong, you cannot expect others to come to the rescue. At least
> not free of charge.

I think you are mistaking the expected level of knowledge of an admin vs
a user.  Users may typically post to an email list (yes even this one)
and are certainly not expected to have knowledge of the underlying
protocols and technologies.

>> This is too much to expect every poster to conform to these
>> expectations, and more importantly there will always be posters who do
>> not regardless of how much you expect it.
>
> Speaking for myself: I don't care one bit about that. My messages are
> processed as they should be, as are those of people with worthwhile
> opinions. If somebody is incapable of setting up their MTA correctly to
> post via this here mailing list, I am not interested in what they might
> have to say about Postfix.

I prefer to be able to see a full conversation rather than having to
hunt through my Spam folder for pieces of it.


Peter

Reply | Threaded
Open this post in threaded view
|

Re: Gmail and spam, a request

Richard Damon
On 4/26/20 10:25 PM, Peter wrote:
>
> I prefer to be able to see a full conversation rather than having to
> hunt through my Spam folder for pieces of it.
>
>
> Peter
>
The solution for the GMail user is to just add a filter for messages
from the list and set the filter to bypass the spam filter, no more
problems with the messages in the spam filter. At the same time you can
put the message into a tag, to keep things organized.

--
Richard Damon

Reply | Threaded
Open this post in threaded view
|

Re: Gmail and spam, a request

Peter Ajamian
In reply to this post by Richard Damon
On 27/04/20 2:02 am, Richard Damon wrote:

> On 4/26/20 8:15 AM, Peter wrote:
>> On 27/04/20 12:00 am, Richard Damon wrote:
>>> Except that if the sender is sending from a domain with an email policy
>>> that effectively says, "This domain is intended to send sensitive
>>> information, please do not accept messages that do not come directly
>>> from us", then it is reasonable to tell the sender that they are sending
>>> messages outside their domains (implied) terms of service, and either
>>> they need to use a different service that is compatible with a mailing
>>> list, or have the domain fix its implied declaration of usage.
>>
>> But that's not what DMARC does.
>
> It is EXACTLY what DMARC does.

You claim that DMARC is supposed to control sensitive information.  It
does nothing of the sort and cannot do anything of the sort.  DNS
records cannot stop someone unauthorized from accessing sensitive
information in an email message.

>> Ummm, no it's not.  DMARC is intended to stop mail From: header spoofing.
>
> And re-mailing the original message is classified as From: header
> spoofing.

Since when?  If you leave the From: header intact how is that spoofing?
Exactly what are you misrepresenting?  That's like saying that if I make
a copy of a document then I am misrepresenting the original.  In fact
changing the From: header which we must do to work around the issues
that DMARC poses is much closer to spoofing (but still is not, imo) than
simply forwarding the message with the headers intact.

> A properly setup DMARC/DKIM (but not just DMARC/SPF) does
> allow remailing if the message is kept identical in the signed respects,
> so DMARC with a broken (or not setup) DKIM can't use re-mailiers at all,
> and one with DMARC/DKIM can only use remailers that don't modify the
> message, including the common adding of a subject 'wart' to identify
> messages from the list or a message footer (or sometimes header) with
> instructions about the list, included out of policy or sometimes even to
> be compliant with local legal requirements.

DKIM is not required for DMARC.

>>> Configuring a domain
>>> with DMARC says that it is intended that message only be accepted if
>>> they come directly from the sender.
>>
>> I call BS on that, and in fact ARC was created specifically to allow
>> third parties to forward DMARC policy messages on without having them
>> flagged as Spam.
>
> ARC is a late to the party attempt to fix the misuse of DMARC. To my
> knowledge it isn't even an accepted standard yet, and it asks for the
> impacted 3rd party to add to its processing to allow it to become an
> 'approved' re-resender. It also starts with the list with being a
> violator until the system 'learns' that it is ok.

Google recognizes it, and in the case of the above mentioned messages it
is likely that ARC would have fixed it so that the message would not
have ended up in my Spam folder.  That said, I already did point out
that there will be servers that enforce DMARC which do not recognize ARC
and as such I would prefer to see other mitigations done that do not
require ARC.  But I simply pointed it out as an official attempt to fix
a shortcoming with DMARC.

> DMARC's purpose is to stop phishing, people pretending to be you when
> they aren't. Mailing list send messages out on Behalf of you, but the
> DMARC protocal wasn't built to handle this case (ARC is trying to fix
> it, but is late to the game).

Which is exactly what I have been saying as well.

> Now, if DMARC had a level below
> quarantine, that said to accept the messages even if they don't pass the
> DMARC validation, and to not treat this violation as likely spam, but
> maybe and a remailer warning, but it doesn't, as it wasn't intended in
> its design to handle this case.

Then bad admins would still misconfigure it and cause problems for
mailing lists.

> Domains using DMARC and allowing users
> to use mailing list are working outside the original design parameters
> of DMARC.

Correct, DMARC was not designed with the needs of mailing lists in mind,
therefore mailing lists must take measures to work around the issues
that DMARC has now caused.

> If a mailing list gets a message from a DMARC enabled host it has just a
> few possible mitigations:
>
> 1) If the sending domain has a proper DMARC/DKIM setup, the list can
> just forward the message without making any modifications that would
> break DKIM, provided that this falls within the policy and laws the list
> run, IF DMARC/DKIM isn't setup properly, this option can't be used.

Normally, yes, however keep in mind that Google is a bolack box and they
recommend that all three of SPF, DKIM and DMARC are configured for the
sender.  I would not put it past them to at least on some degree affect
the SPAM score if, for example, if the DKIM passes against the From:
domain but SPF does not.  With that in mind, it is likely best if the
list server makes sure that all elements of DMARC pass and not just DKIM
or SPF.

> 2) The list can violate the EMail RFCs, change the From header to be the
> list (thus claiming authorship of the message) and distribute the
> message this way. This makes if hard to identify the real author of the
> message, as it no longer is in the from header, so doesn't show in many
> MUA. This is the common DMARC mitigation.

Right, and this is the standard recommended mitigation, but it is
generally only performed when it has to (ie when there is a DMARC policy
set to reject the message otherwise).  Also it is arguable if it truely
violates the RFCs if you're claiming ownership.  If it does then it
could be said that it violates the RFCs just as much when someone hits
the "Forward" button in their MUA, although this capability and action
is quite common and has been for decades.

> 3) The list can just not allow people from DMARC enable domains to post
> (which is ultimately respecting the implied wishes of the domain
> publishing a DMARC record). When YAHOO and AOL first abused DMARC in
> this way around 2014, this was one option that was put forth in the
> Mailing List community.

This is certainly an option, although I would say quite a draconian one
and it is arguable that the DMARC policy actually reflects the wishes of
the domain owner in this way.  Usually a strict DMARC policy is in place
simply to prevent spoofing, and not to prevent someone from sending mail
to a mailing list.

> 4) Send the message normally and take all the DMARC violations (and
> possible non-reception or spam classification), this also can cause the
> receiving domains that respect DMARC to send bounce messages to the
> mailing list which may cause those recipients to get unsubscribed from
> the list. These violations may also impact the reputation of the list
> when relaying other messages that don't have the DMARC issue.

This seems to be the approach that this mailing list is currently
taking.  I don't believe that very many ESPs actually send bounce
messages in response to DMARC violations, the general response is to
deliver the message to the recipient's SPAM folder.  It can, however,
also affect the list server's IP reputation.

You forgot option 5 - ARC mitigation.  While this option is not yet
widely supported major ESPs such as google and I believe Microsoft do
appear to support it now and adoption should only grow with time.  The
obvious drawback is that there will still be servers that enforce DMARC
policies but do not recognize ARC yet and to those servers it will look
like a DMARC violation and you end up with situation 4 above.

My personal preference at this time is option 2.  At some future time
after ARC is more widely adopted I think we should change to adopt ARC
instead.


Peter
Reply | Threaded
Open this post in threaded view
|

Re: Gmail and spam, a request

Richard Damon
On 4/26/20 11:47 PM, Peter wrote:

> On 27/04/20 2:02 am, Richard Damon wrote:
>> On 4/26/20 8:15 AM, Peter wrote:
>>> On 27/04/20 12:00 am, Richard Damon wrote:
>>>> Except that if the sender is sending from a domain with an email
>>>> policy
>>>> that effectively says, "This domain is intended to send sensitive
>>>> information, please do not accept messages that do not come directly
>>>> from us", then it is reasonable to tell the sender that they are
>>>> sending
>>>> messages outside their domains (implied) terms of service, and either
>>>> they need to use a different service that is compatible with a mailing
>>>> list, or have the domain fix its implied declaration of usage.
>>>
>>> But that's not what DMARC does.
>>
>> It is EXACTLY what DMARC does.
>
> You claim that DMARC is supposed to control sensitive information.  It
> does nothing of the sort and cannot do anything of the sort.  DNS
> records cannot stop someone unauthorized from accessing sensitive
> information in an email message.
It is for something like an alert that there is a suspecious use of your
credit card, so please check with your bank. The sort of thing many of
us get a phish attacks.

>
>>> Ummm, no it's not.  DMARC is intended to stop mail From: header
>>> spoofing.
>>
>> And re-mailing the original message is classified as From: header
>> spoofing.
>
> Since when?  If you leave the From: header intact how is that
> spoofing? Exactly what are you misrepresenting?  That's like saying
> that if I make a copy of a document then I am misrepresenting the
> original.  In fact changing the From: header which we must do to work
> around the issues that DMARC poses is much closer to spoofing (but
> still is not, imo) than simply forwarding the message with the headers
> intact.
If I take a measage that has been protected by just DMARC/SPF, and
forward it, it will fail DMARC and be considered a spoof. Yes, in our
personal understanding, taking an email message in on a mailing list and
resending it out, maybe with some minor administrative changes isn't a
spoof, but to DMARC is it. THAT is part of the issue with DMARC.

>
>> A properly setup DMARC/DKIM (but not just DMARC/SPF) does
>> allow remailing if the message is kept identical in the signed respects,
>> so DMARC with a broken (or not setup) DKIM can't use re-mailiers at all,
>> and one with DMARC/DKIM can only use remailers that don't modify the
>> message, including the common adding of a subject 'wart' to identify
>> messages from the list or a message footer (or sometimes header) with
>> instructions about the list, included out of policy or sometimes even to
>> be compliant with local legal requirements.
>
> DKIM is not required for DMARC.
Yes, and DMARC without DKIM will break EVERY email list (without careful
updates by the domain manager), as the list will not be one of the
approved IP that mail from that domain is allowed to come from.

>
>>>> Configuring a domain
>>>> with DMARC says that it is intended that message only be accepted if
>>>> they come directly from the sender.
>>>
>>> I call BS on that, and in fact ARC was created specifically to allow
>>> third parties to forward DMARC policy messages on without having them
>>> flagged as Spam.
>>
>> ARC is a late to the party attempt to fix the misuse of DMARC. To my
>> knowledge it isn't even an accepted standard yet, and it asks for the
>> impacted 3rd party to add to its processing to allow it to become an
>> 'approved' re-resender. It also starts with the list with being a
>> violator until the system 'learns' that it is ok.
>
> Google recognizes it, and in the case of the above mentioned messages
> it is likely that ARC would have fixed it so that the message would
> not have ended up in my Spam folder.  That said, I already did point
> out that there will be servers that enforce DMARC which do not
> recognize ARC and as such I would prefer to see other mitigations done
> that do not require ARC.  But I simply pointed it out as an official
> attempt to fix a shortcoming with DMARC.

ARC is a sign that DMARC is broken, that it wasn't intended for the uses
that it is now being used on. It was NOT a part of the initial DMARC
proposal, there is no sign at all of it in the design. It is a patch fix
to handle a problem that came up when DMARC was misused. we are now 6
years after DMARC was misused, it took 3 years from that to have initial
proposals, 5 years to get an 'experimental' RFC, which is our current
state. It basically says, hey, all you mailing list out there, here is
an idea we have, why don't you all implement this to see if it works, we
likely will need to tweak the details in the future, but thats ok, you
can just make the changes when we do.

That is a bit like some Doctors coming out with a medicine that looks
like it will help against COVID-19, we haven't had a chance to run a
full set of trials, but early tests show it won't kill you, at least not
quickly, so we want everyone to take the shot. Oh, and we have persuaded
a number of grocery chains that they will insist that you show proof of
taking it before you can come in to shop. Based on this trial, we hope
to improve the medicine.

>
>> DMARC's purpose is to stop phishing, people pretending to be you when
>> they aren't. Mailing list send messages out on Behalf of you, but the
>> DMARC protocal wasn't built to handle this case (ARC is trying to fix
>> it, but is late to the game).
>
> Which is exactly what I have been saying as well.
The problem is it calls most mailing list phish.

>
>> Now, if DMARC had a level below
>> quarantine, that said to accept the messages even if they don't pass the
>> DMARC validation, and to not treat this violation as likely spam, but
>> maybe and a remailer warning, but it doesn't, as it wasn't intended in
>> its design to handle this case.
>
> Then bad admins would still misconfigure it and cause problems for
> mailing lists.
>
>> Domains using DMARC and allowing users
>> to use mailing list are working outside the original design parameters
>> of DMARC.
>
> Correct, DMARC was not designed with the needs of mailing lists in
> mind, therefore mailing lists must take measures to work around the
> issues that DMARC has now caused.
NO! That isn't how standards are supposed to work.

>
>> If a mailing list gets a message from a DMARC enabled host it has just a
>> few possible mitigations:
>>
>> 1) If the sending domain has a proper DMARC/DKIM setup, the list can
>> just forward the message without making any modifications that would
>> break DKIM, provided that this falls within the policy and laws the list
>> run, IF DMARC/DKIM isn't setup properly, this option can't be used.
>
> Normally, yes, however keep in mind that Google is a bolack box and
> they recommend that all three of SPF, DKIM and DMARC are configured
> for the sender.  I would not put it past them to at least on some
> degree affect the SPAM score if, for example, if the DKIM passes
> against the From: domain but SPF does not.  With that in mind, it is
> likely best if the list server makes sure that all elements of DMARC
> pass and not just DKIM or SPF.
>
>> 2) The list can violate the EMail RFCs, change the From header to be the
>> list (thus claiming authorship of the message) and distribute the
>> message this way. This makes if hard to identify the real author of the
>> message, as it no longer is in the from header, so doesn't show in many
>> MUA. This is the common DMARC mitigation.
>
> Right, and this is the standard recommended mitigation, but it is
> generally only performed when it has to (ie when there is a DMARC
> policy set to reject the message otherwise).  Also it is arguable if
> it truely violates the RFCs if you're claiming ownership.  If it does
> then it could be said that it violates the RFCs just as much when
> someone hits the "Forward" button in their MUA, although this
> capability and action is quite common and has been for decades.
>
DMARC, when used on a domain that allows use of re-mailers is
fundamentally flawed. Note, DMARC isn't even 'Standard Track', it is
just an informational standard. That means there is currently NO attempt
to make it part of the official EMail Standards, it is merely a piece of
information designed to allow two domains that want to transfer some
information to do so, it isn't supposed to have impact on third parties
(that would need to be Standards Track).

>> 3) The list can just not allow people from DMARC enable domains to post
>> (which is ultimately respecting the implied wishes of the domain
>> publishing a DMARC record). When YAHOO and AOL first abused DMARC in
>> this way around 2014, this was one option that was put forth in the
>> Mailing List community.
>
> This is certainly an option, although I would say quite a draconian
> one and it is arguable that the DMARC policy actually reflects the
> wishes of the domain owner in this way.  Usually a strict DMARC policy
> is in place simply to prevent spoofing, and not to prevent someone
> from sending mail to a mailing list.

But, by the way the DMARC standard is set up, a domain that publishes a
DMARC policy is effectively saying that they don't wish for their users
to use mailing list, (or if they DMARC/DKIM sign mailing lists that
administratively modify messages, which is historically common). When
Yahoo and AOL did this in 2014 they effectively BROKE the Email
standards. They were able to get away with it because they were the big
gorillas of the industry. The primary reason the mailing list community
didn't just decide to ban Yahoo users was compassion. It was realized
that banning Yahoo users from using mailing list to keep them from being
broken would just hurt the little guy, the users of those systems who
chose it because they didn't require the user to be very computer savvy.
That those users were likely largely 'captive' not wanting to change to
other providers that they would need to learn a totally new interface.
That if those users complained, Yahoo wouldn't really care, real mailing
list users don't make a large enough proportion of their user base to
impact them, especially considering the lock-in factor.

>
>> 4) Send the message normally and take all the DMARC violations (and
>> possible non-reception or spam classification), this also can cause the
>> receiving domains that respect DMARC to send bounce messages to the
>> mailing list which may cause those recipients to get unsubscribed from
>> the list. These violations may also impact the reputation of the list
>> when relaying other messages that don't have the DMARC issue.
>
> This seems to be the approach that this mailing list is currently
> taking.  I don't believe that very many ESPs actually send bounce
> messages in response to DMARC violations, the general response is to
> deliver the message to the recipient's SPAM folder.  It can, however,
> also affect the list server's IP reputation.
>
> You forgot option 5 - ARC mitigation.  While this option is not yet
> widely supported major ESPs such as google and I believe Microsoft do
> appear to support it now and adoption should only grow with time.  The
> obvious drawback is that there will still be servers that enforce
> DMARC policies but do not recognize ARC yet and to those servers it
> will look like a DMARC violation and you end up with situation 4 above.
>
> My personal preference at this time is option 2.  At some future time
> after ARC is more widely adopted I think we should change to adopt ARC
> instead.
>
>
> Peter


--
Richard Damon

Reply | Threaded
Open this post in threaded view
|

Re: Gmail and spam, a request

Ralph Seichter-2
In reply to this post by Peter Ajamian
* [hidden email]:

> DKIM is not required for DMARC.

Now you're just being ridiculous, and have earned yourself a membership
in my killfile. "DMARC [...] builds on the widely deployed SPF and DKIM
protocols" (https://dmarc.org "What is DMARC?").

-Ralph
Reply | Threaded
Open this post in threaded view
|

Re: Gmail and spam, a request

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

"... 
you can use DMARC with only SPF – and absolutely should, at least as far as enabling reporting – 
..." 



On Mon, Apr 27, 2020, 3:55 PM Ralph Seichter <[hidden email]> wrote:
* [hidden email]:

> DKIM is not required for DMARC.

Now you're just being ridiculous, and have earned yourself a membership
in my killfile. "DMARC [...] builds on the widely deployed SPF and DKIM
protocols" (https://dmarc.org "What is DMARC?").

-Ralph
Reply | Threaded
Open this post in threaded view
|

Re: Gmail and spam, a request

Ralph Seichter-2
* pgndev:

> https://dmarc.org/2017/03/can-i-use-dmarc-if-i-have-only-deployed-spf/
>
> "...
> you can use DMARC with only SPF – and absolutely should, at least as far as
> enabling reporting –
> ..."

Tut, tut... Partial quotes, out of context. How desperate some of you
have become. The relevant paragraph reads as follows:

  [People] knew the recommendation is to use both DKIM and SPF, and were
  concerned that their organizations couldn’t benefit from DMARC without
  DKIM. The short answer is that you can use DMARC with only SPF – and
  absolutely should, at least as far as enabling reporting – but there
  are some very important questions you have to answer before moving
  past that to a DMARC policy that would block unauthenticated
  messages.

Anybody who uses blocking DMARC policies without DKIM for domains used
on mailing lists: Please stop moaning and do your homework. You're just
wasting time.

-Ralph
123