Big problem with this mailing list and Majordomo regarding DMARC

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

Re: Big problem with this mailing list and Majordomo regarding DMARC

Richard Damon
On 4/19/19 11:22 PM, Bill Cole wrote:
> On 19 Apr 2019, at 22:50, Richard Damon wrote:
>
>> Note also, these RFCs are just Standards Track, which says that they are
>> not yet 'full standards' but still evolving, and I believe that one of
>> the issues that needs to be worked out is to figure out how to improve
>> their interoperability for general emails with traditional mailing lists.
> Sadly, no. See https://www.rfc-editor.org/info/std76
>
Remembering more clearly, it isn't DKIM itself that causes problems, as
the system with the MLM could easily resign the messages using the
sender domain which is specifically allowed.

Where the issue comes is with DMARC, which restricts the DKIM protocol
to be aligned with the From line of the message, and thus the MLM can't
make the message pass the DMARC settings of the sending domain. It is
DMARC which breaks the traditional operation of a MLM, and the use of
which implies that the sender should not be using such tools.

--
Richard Damon

Reply | Threaded
Open this post in threaded view
|

Re: Big problem with this mailing list and Majordomo regarding DMARC

Reto
On Sat, Apr 20, 2019 at 07:31:06AM -0400, Richard Damon wrote:
> Where the issue comes is with DMARC, which restricts the DKIM protocol
> to be aligned with the From line of the message, and thus the MLM can't
> make the message pass the DMARC settings of the sending domain. It is
> DMARC which breaks the traditional operation of a MLM, and the use of
> which implies that the sender should not be using such tools.

Now that's a bit dramatic isn't it?
A mailing list *can* work with dmarc just fine if it doesn't modify the protected headers.
That doesn't seem to be particularely complicated assuming Headers like List-Unsubscribe et al can still be added.

Just don't modify the subject and the body and you should be fine.
Reply | Threaded
Open this post in threaded view
|

Re: Big problem with this mailing list and Majordomo regarding DMARC

Richard Damon
On 4/20/19 8:08 AM, Reto wrote:

> On Sat, Apr 20, 2019 at 07:31:06AM -0400, Richard Damon wrote:
>> Where the issue comes is with DMARC, which restricts the DKIM protocol
>> to be aligned with the From line of the message, and thus the MLM can't
>> make the message pass the DMARC settings of the sending domain. It is
>> DMARC which breaks the traditional operation of a MLM, and the use of
>> which implies that the sender should not be using such tools.
> Now that's a bit dramatic isn't it?
> A mailing list *can* work with dmarc just fine if it doesn't modify the protected headers.
> That doesn't seem to be particularely complicated assuming Headers like List-Unsubscribe et al can still be added.
>
> Just don't modify the subject and the body and you should be fine.
>
One issue is that some legal advisors will state that List-Unsubscribe
might not be good enough to meet the requirements of clearly visible
unsubscription instructions since it is NOT required that a MUA handle
that header in any particular manner if at all. That means that to
clearly meet the legal requirement in those those jurisdiction must
break the DKIM signature.

Mailing list also have traditionally modified other headers, like
Reply-To to make replies by default to go to the list, and frequently
the subject to allow for easy filtering of the messages from the list on
MUAs that may be somewhat limited in their filtering capability. This
was common existing practice, which DKIM acknowledged and provided for
by allowing resigning aligned to the Sender, but DMARC broke.

To meet the Mail RFCs the Mailing list should modify the Sender: field,
so if that was signed (as was pointed out is recommended by DKIM) the
signatures will be broken, and since DMARC requires alignment to From:
(which the RFCs says should be the Author of the message, so should be
the original sender), a MLM manager can be forced to break some RFC to
be able to deliver the message.

DMARC by itself isn't that bad, as the original intent was, at least in
part, to protect transactional emails, and those should generally not go
through the sort of system that have issues with it. The issue with
DMARC was its adoption by mailing services that did not meet that model,
and who did not inform their users of the implied restrictions on their
users of the use of those services (and some [yahoo] even ran their own
competing MLM service that for their users could 'cheat' and sign the
modified messages).

When the issue first came up, there was a move to ask the operators of
mailing lists to just tell their subscribers from the domains that
adopted the abusive settings that caused the issues that they were no
longer allowed to post through the list (since that IS the real meaning
of a strict DMARC setting), but it was decided that such a move would
just be a punishment on the innocent and less technically competent
user, and not those that ran the domains.

There are still people who propose that to demonstrate the issue, that
all MLM should be setup to automatically reject any message, and not use
a RFC-incompliant workaround (like munging From:) that would create a
DMARC exception, and some go as far as suggest that the rejection
message should also be copied to the DMARC team to show them the extent
of their breakage of the Mail System.

--
Richard Damon

Reply | Threaded
Open this post in threaded view
|

Re: Big problem with this mailing list and Majordomo regarding DMARC

TG Servers


On 20/04/2019 14:59, Richard Damon wrote:

> On 4/20/19 8:08 AM, Reto wrote:
>> On Sat, Apr 20, 2019 at 07:31:06AM -0400, Richard Damon wrote:
>>> Where the issue comes is with DMARC, which restricts the DKIM protocol
>>> to be aligned with the From line of the message, and thus the MLM can't
>>> make the message pass the DMARC settings of the sending domain. It is
>>> DMARC which breaks the traditional operation of a MLM, and the use of
>>> which implies that the sender should not be using such tools.
>> Now that's a bit dramatic isn't it?
>> A mailing list *can* work with dmarc just fine if it doesn't modify the protected headers.
>> That doesn't seem to be particularely complicated assuming Headers like List-Unsubscribe et al can still be added.
>>
>> Just don't modify the subject and the body and you should be fine.
>>
> To meet the Mail RFCs the Mailing list should modify the Sender: field,
> so if that was signed (as was pointed out is recommended by DKIM) the
> signatures will be broken, and since DMARC requires alignment to From:
> (which the RFCs says should be the Author of the message, so should be
> the original sender), a MLM manager can be forced to break some RFC to
> be able to deliver the message.
>
This is not a 100% clear and maybe was just forgotten to delete. RFC6376
does not explicitely recommend to sign Sender in the "Recommended
Signature Content" which is pointed out in 5.4.1 anymore.
While it is true that there is still the sentence in 5.4 "For this
reason, signing fields present in the message such as Date, Subject,
Reply-To, Sender, and all MIME header fields are highly advised." this
is just out of an "Informative Operations Note" and maybe a relict
of the old (and deprecated RFC4871).

Because if you look further in 5.4.1 "Recommended Signature Content" the
Sender field is not there anymore, the list reads
"From, Reply-To, Subject, Date, To, Cc, Resent-Date, Resent-From,
Resent-To, Resent-Cc, In-Reply-To, References, List-Id, List-Help,
List-Unsubscribe, List-Subscribe, List-Post, List-Owner, List-Archive"
and leaves "Message-ID, In-Reply-To and References" more open

This was clearly revised from RFC4871 5.5 "Recommended Signature"
content which reads a bit different and definitely included more fields
"From, Sender, Reply-To, Subject, Date, Message-ID, To, Cc,
MIME-Version, Content-Type, Content-Transfer-Encoding, Content-ID, Content-
Description, Resent-Date, Resent-From, Resent-Sender, Resent-To,
Resent-Cc, Resent-Message-ID, In-Reply-To, References, ,List-Id, List-Help,
List-Unsubscribe, List-Subscribe, List-Post, List-Owner, List-Archive"

Sender, MIME and Content-fields were clearly reworked and taken out
there whereas the common part of 5.4 was just copied maybe.

https://tools.ietf.org/html/rfc6376#section-5.4.1
https://tools.ietf.org/html/rfc4871#section-5.5
Reply | Threaded
Open this post in threaded view
|

Re: Big problem with this mailing list and Majordomo regarding DMARC

Bill Cole-3
In reply to this post by Ralph Seichter-2
On 20 Apr 2019, at 6:38, Ralph Seichter wrote:

> Signing a non-existing (!) header. Right. Mind if I watch? :-)

There's no need to watch, if you can imagine what it would look like
from the description in the specification of how to include non-existent
headers in a signature.

The purpose of "over-signing" headers (you can also explicitly include
multiple instances of any header) is to signal the addition of
particular headers that might be misleading in forwarded or otherwise
manipulated messages.

DKIM has features which reflect more concern for conceptual
"vulnerabilities" than operational robustness. The mere existence of the
'simple' header canonicalization scheme is an example of this: it is
broken by semantically null transformations that may be required in
transit. One could argue that the 'relaxed' canonicalization is only
slightly better, as it is broken by fix-up of addresses and address
lists (e.g. To, Cc) which are in formal violation of RFC822 et seq.

--
Bill Cole
[hidden email] or [hidden email]
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Available For Hire: https://linkedin.com/in/billcole
Reply | Threaded
Open this post in threaded view
|

Re: Big problem with this mailing list and Majordomo regarding DMARC

Ralph Seichter-2
* Bill Cole:

> There's no need to watch, if you can imagine what it would look like
> from the description in the specification of how to include non-existent
> headers in a signature.

I'm aware of RFC 4871 section 5.4. "The From header field MUST be
signed", so here's where signing non-existing headers is of interest.

Sender does not need to be signed if it does not exist. "signing fields
*present* in the message such as Date, Subject, Reply-To, Sender, and
all MIME header fields are highly advised." (my emphasis). Signing a
non-existing Sender header to prevent a ML from adding it is bull in my
opinion, and who does that should not complain.

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

Re: Big problem with this mailing list and Majordomo regarding DMARC

Benny Pedersen-2
In reply to this post by Dominic Raferd
Dominic Raferd skrev den 2019-04-20 12:02:
> On Fri, 19 Apr 2019 at 14:11, Benny Pedersen <[hidden email]> wrote:
>
>> i have now disabled milters from trusted maillists ips
>
> How did you do this? It might help me. I have missed some of this
> thread because OP's mails are blocked (correctly of course) by my
> opendmarc.


# cat /etc/postfix/smtpd_milters_map.cidr
#
# postfix maillist disable all milters

168.100.1.3                             DISABLE
168.100.1.4                             DISABLE
168.100.1.7                             DISABLE
2604:8d00:0:1::3                        DISABLE
2604:8d00:0:1::4                        DISABLE
2604:8d00:0:1::7                        DISABLE

# grep milter main.cf
smtpd_milter_maps = cidr:/etc/postfix/smtpd_milter_maps.cidr

add ips to postscreen whitelist if you use rbl that block posstfix
maillist
Reply | Threaded
Open this post in threaded view
|

Re: Big problem with this mailing list and Majordomo regarding DMARC

Dominic Raferd


On Sun, 21 Apr 2019 at 13:16, Benny Pedersen <[hidden email]> wrote:
Dominic Raferd skrev den 2019-04-20 12:02:
> On Fri, 19 Apr 2019 at 14:11, Benny Pedersen <[hidden email]> wrote:
>
>> i have now disabled milters from trusted maillists ips
>
> How did you do this? It might help me. I have missed some of this
> thread because OP's mails are blocked (correctly of course) by my
> opendmarc.


# cat /etc/postfix/smtpd_milters_map.cidr
#
# postfix maillist disable all milters

168.100.1.3                             DISABLE
168.100.1.4                             DISABLE
168.100.1.7                             DISABLE
2604:8d00:0:1::3                        DISABLE
2604:8d00:0:1::4                        DISABLE
2604:8d00:0:1::7                        DISABLE

# grep milter main.cf
smtpd_milter_maps = cidr:/etc/postfix/smtpd_milter_maps.cidr

add ips to postscreen whitelist if you use rbl that block posstfix
maillist

Thanks, I've now implemented that
123