Re: [mailop] Mailing Lists and domains with DMARC reject
Would a MUA send a POST to a known domain if it was found on a message coming from an unknown, or anyway different domain? Maybe. It's quite common for a message to come from some company and the links to point back to the ESP. Isn't it difficult to agree on opaque tokens in that case? No. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Mailing Lists and domains with DMARC reject
On Thu 09/Mar/2023 19:21:36 +0100 John R Levine via mailop wrote: Yes, the idea was to prevent malicious unsubs by sending fake spam with someone else's one-click unsub. Would a MUA send a POST to a known domain if it was found on a message coming from an unknown, or anyway different domain? Maybe. It's quite common for a message to come from some company and the links to point back to the ESP. Isn't it difficult to agree on opaque tokens in that case? Best Ale -- ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Mailing Lists and domains with DMARC reject
Yes, the idea was to prevent malicious unsubs by sending fake spam with someone else's one-click unsub. Would a MUA send a POST to a known domain if it was found on a message coming from an unknown, or anyway different domain? Maybe. It's quite common for a message to come from some company and the links to point back to the ESP. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Mailing Lists and domains with DMARC reject
On Wed 08/Mar/2023 18:39:37 +0100 John R Levine via mailop wrote: And why does RFC8058 require that fields such as List-Unsubscribe-Post: MUST be signed? Is it special "One click" case? I was not interested in it yet... Yes, the idea was to prevent malicious unsubs by sending fake spam with someone else's one-click unsub. Would a MUA send a POST to a known domain if it was found on a message coming from an unknown, or anyway different domain? It may be that in the tradeoff between resilience and security the latter wins. In that case shouldn't RFC8058 have modified Section 5.4.1 of RFC6376, Recommended Signature Content? Should software that defines the default fields to sign after that section add List-Unsubscribe-Post to that list? Best Ale -- ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Mailing Lists and domains with DMARC reject
On Wed 08/Mar/2023 22:27:57 +0100 Ángel via mailop wrote:
On 2023-03-08 at 11:24 +0100, Alessandro Vesely wrote:
On Tue 07/Mar/2023 20:02:48 +0100 Slavko wrote:
Why do you sign Content-Type: since you know it is going to be
changed?
Do you mean exactly me, or it was generic question? If you mean me:
Do you want change the text/plain message, eg. to multipart/alternative
with text/html appended? Of course, in my case that change will invalidate
body signature too (as i sign whole body), but anyway, it constructs core
of message, thus (IMO) fulfill RFC.
Yes, I meant you, since you (are among the ones who) do it.
The change to multipart can only happen using the deprecated l=. It allows to
completely replace the body appearance. As you don't use l=, the only added
protection is against an improbable collision between the original bh= and the
hash of the modified body.
There are more ways to change a Content-type for abuse.
Suppose there is a web form that is expected to send a plain text message
saying:
"Hello Alessandro
Thanks for registering on example.com, please click the following link to validate
your account: https://example.com/register...";
These kind of forms are already abused by using "names" such as "buy our viagra
at great price on http://spamurl.com";
URLs don't depend on Content-Type:, do they?
The "I received a scam letter from Paypal" thread a few months ago is also based
on the same concept.
That turned out to be authentic, IIRC.
Now, let's suppose that email is DKIM-signed but the Content-type: text/plain header
is not. And the form is filled out by «Bobby * { color: white; background-color:
white; } .phish * { color: black}Important notification from your bank
Your password has expired. Please https://phishing.com";>Renew it here»
and attacker changes the Content-type from text/plain to text/html...
Is that content going to replace «Alessandro» in the plain/text message from
the generated message? The culprit seems to be rather the input sanitizing
than the signing.
Another venue would be changing the charset to utf-7 This was a common
way of bypassing XSS filters on browsers. It is now unsupported by all
browsers, and forbidden by the spec [1]. I don't know if there is any
MUA which allows that (or even used to support it)
That requires the original text to already contain the exploit. Perhaps the
plain text message was exemplifying it?
Determining which headers to sign (or not to sign) is complex, brittle
and reasons for that unintuitive and not well-known. A reference
document that provided guidance (if not even a direct recipe) would
surely be helpful to the email community.
I agree that some kind of transactional messages can bear paranoid signatures.
They also deserve p=reject.
Ordinary messages, which can expect to be forwarded or slightly modified could
keep a lower profile, couldn't they?
I understand that the only advantage of signing lightly is for the very few
people who can recover that kind of signatures after MLM transformation, so it
seems to be a lost argument...
1-
https://html.spec.whatwg.org/multipage/parsing.html#character-encodings
I hope Javascript in email messages does not run...
Best
Ale
--
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
Re: [mailop] Mailing Lists and domains with DMARC reject
On 2023-03-08 at 11:24 +0100, Alessandro Vesely wrote:
> On Tue 07/Mar/2023 20:02:48 +0100 Slavko wrote:
> >
> > > Why do you sign Content-Type: since you know it is going to be
> > > changed?
> >
> > Do you mean exactly me, or it was generic question? If you mean me:
> >
> > Do you want change the text/plain message, eg. to multipart/alternative
> > with text/html appended? Of course, in my case that change will invalidate
> > body signature too (as i sign whole body), but anyway, it constructs core
> > of message, thus (IMO) fulfill RFC.
>
> Yes, I meant you, since you (are among the ones who) do it.
>
> The change to multipart can only happen using the deprecated l=. It allows
> to
> completely replace the body appearance. As you don't use l=, the only added
> protection is against an improbable collision between the original bh= and
> the
> hash of the modified body.
There are more ways to change a Content-type for abuse.
Suppose there is a web form that is expected to send a plain text message
saying:
"Hello Alessandro
Thanks for registering on example.com, please click the following link to
validate
your account: https://example.com/register...";
These kind of forms are already abused by using "names" such as "buy our viagra
at great price on http://spamurl.com";
The "I received a scam letter from Paypal" thread a few months ago is also based
on the same concept.
Now, let's suppose that email is DKIM-signed but the Content-type: text/plain
header
is not. And the form is filled out by «Bobby * { color: white;
background-color:
white; } .phish * { color: black}Important
notification from your bank
Your password has expired. Please https://phishing.com";>Renew it
here»
and attacker changes the Content-type from text/plain to text/html...
Another venue would be changing the charset to utf-7 This was a common
way of bypassing XSS filters on browsers. It is now unsupported by all
browsers, and forbidden by the spec [1]. I don't know if there is any
MUA which allows that (or even used to support it)
Determining which headers to sign (or not to sign) is complex, brittle
and reasons for that unintuitive and not well-known. A reference
document that provided guidance (if not even a direct recipe) would
surely be helpful to the email community.
1-
https://html.spec.whatwg.org/multipage/parsing.html#character-encodings
older versions were even more explicit that UTF-7 must not be used
https://github.com/whatwg/html/commit/a73180679a40fce96b8e8fb6dfa5815a9bce30eb#diff-41cf6794ba4200b839c53531555f0f3998df4cbb01a4d5cb0b94e3ca5e23947dL14674
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
Re: [mailop] Mailing Lists and domains with DMARC reject
Yeah, RFC4871 was a proposed standard, RFC6376, four years later became an Internet standard. Once there was a level in between... Seems that 4 years was not enough ;-) Or we understand idea behind that RFC wrongly... Keep in mind that DMARC was invented long after SPF and DKIM. Also that the original goal of DMARC was to protect heavily phished domains like paypal.com and its authors did not expect anyone to use it on domains that send mail to lists. It was several years later that AOL and Yahoo started abusing DMARC to outsource the cost of phishes using address books that they let crooks steal. And why does RFC8058 require that fields such as List-Unsubscribe-Post: MUST be signed? Is it special "One click" case? I was not interested in it yet... Yes, the idea was to prevent malicious unsubs by sending fake spam with someone else's one-click unsub. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Mailing Lists and domains with DMARC reject
Hi, Dňa 8. marca 2023 15:18:49 UTC používateľ Stephen Frost via mailop napísal: >Certainly doesn't seem to be a common issue. Yes, as i wrote, it isn't common, but it happens... I had even less scientific approach, as i had manually to exclude messages from lists... But my goal was not to inspect it in depth, only see if it happens. After i realized that it happens, i removed this logging. regards -- Slavko https://www.slavino.sk/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Mailing Lists and domains with DMARC reject
Ahoj,
Dňa Wed, 8 Mar 2023 11:24:54 +0100 Alessandro Vesely via mailop
napísal:
> I slightly lean toward the hypothesis of our understanding the idea
> behind that RFC wrongly, because, ...
IMO we can discuss it in more details, but as i see how many people are
interested (and contributed) in this topic, we can (should) discuss it
out of list. If you are interested to continue, do not afraid contact
me directly (end we will see, if my English is enough for that). ;-)
> It was already discussed that the URL (presumably pointing to the
> same domain) must include an opaque token by which the target can
> check authenticity.
IMO purpose is (can be) to one (not always end user) can notice its
change before it post request to it... My MUAs doesn't support
one-click unsubscribes (or at least i am not aware of it), but
AFAIK there are others which do it. Signing that header, its value
becomes more trusted, with failed DKIM it becomes untrusted.
But that are only my thinking about it...
> I'm thinking to add a third header field list. From OpenDKIM, I have
> requiredhdrs, which are the header fields to be signed /if they
> exist/. Then I have oversignhdrs, which are the ones to
> unconditionally append to h=. The third list would contain the
> fields to be signed once even if they don't exist. I'd put Subject:,
> To: and Cc: in the third list, for example.
>
> Do you have such settings?
Of course, from start of my DKIM signing ;-)
I initially get inspiration from rspamd's default settings [1], which
use similar groups of headers. Exim allows me to define three types (per
header base):
+ sign if exists, oversign if not (Header)
+ always oversign (+Header)
+ sign if exists (=Header)
By using exim's expansions capability one can simple achieve fourth
possibility:
+ oversign if exists (${if def:h_Header:}{+Header}})
IMO that is the easier part. The hard part is to decide which header add
to which group and why/when. But for now i use one common list, which
differs on per message basis only by which headers are included, for
all domains. No more heuristics is applied.
From my notes (i have not as nice formatting in config, and i use
slightly different list now), but one can get idea (IIRC it was
rspamd's table converted to exim syntax) -- the colon is list item
separator:
+From:+Reply-To:+Subject:+To:+Cc\
${if def:h_Sender: {:+Sender}}\
${if def:h_Date: {:+Date}}\
${if def:h_Message-Id: {:+Message-Id}}\
${if def:h_Mime-Version: {:+Mime-Version}}\
${if def:h_Content-Description: {:+Content-Description}}\
${if def:h_Content-Id: {:+Content-Id}}\
${if def:h_Content-Type: {:+Content-Type}}\
${if def:h_Content-Type-Encoding: {:+Content-Type-Encoding}}\
${if def:h_In-Reply-To: {:+In-Reply-To}}\
${if def:h_References: {:+References}}\
${if def:h_Openpgp: {:+Openpgp}}\
${if def:h_Autocrypt: {:+Autocrypt}}\
:=Resent-To:=Resent-Cc:=Resent-Date:=Resent-From:=Resent-Sender:=Resent-Message-Id\
:=List-Archive:=List-Id:=List-Help:=List-Owner:=List-Unsubscribe:=List-Unsubscribe-Post\
:=List-Subscribe:=List-Post
This can be divided into three parts:
+ first line is always oversing list, doesn't matter if presented in
message or not
+ last three lines are sign, but only if presented in message
+ rest is oversign, if presented in message
BTW i revisited my idea about best practices. It can be as simple, as
list of headers, with three basic states -- always (over)sing, never
sign and "consider carefully". The last state then will be elaborated
more detailed, with description when and why it can be changed on
transport, to even inexperienced admins can understand/choose what is
appropriate. Eg with three column with cases -- when to sign, when to
oversign and when to not sign.
[1] https://rspamd.com/doc/modules/dkim_signing.html
> The change to multipart can only happen using the deprecated l=. It
> allows to completely replace the body appearance. As you don't use
> l=, the only added protection is against an improbable collision
> between the original bh= and the hash of the modified body.
Did you consider change only Content-Type, to fool clients to open body
in other application with same (yet unknown) vulnerability? My MUA
doesn't work with DKIM by any way, but others can, and failed DKIM can
contribute to score, that message can be rejected -- that is my idea.
You silently ignored my note, that i consider that header as
"constructing core of message", thus valid candidate to sign it.
Anyway, you described cases, where signing this header is not needed
as DKIM will fail anyway, and i agree. As i consider performance impact
to sign one more header as negligible, thus it must not matter. But
perhaps i ask wrong question, i will try another -- what is (can be)
wrong when it is signed?
regards
--
Slavko
https://www.slavino.sk
pgpNvZjtbY0c7.pgp
Description: Digitálny podpis OpenPGP
___
mailop m
Re: [mailop] Mailing Lists and domains with DMARC reject
Greetings, * Slavko via mailop (mailop@mailop.org) wrote: > Dňa Mon, 6 Mar 2023 17:41:45 -0500 Stephen Frost via mailop > napísal: > > > I was interesting in this, thus i log DKIM signed headers list (not > > > from ML) for some weeks, oversigned List-* headers are not common, > > > but happens. > > > > I'm curious where it does happen and isn't actually from a mailing > > list.. The List-* header would presumably be empty in that case and > > yet still included in the signature? I realize it's possible but ... > > ugh. > > I agree and i consider this as "ugh" too. IMO if message is not from ML > these headers does not construct core of message ;-) > > Initially i noticed it in my job's email. I didn't see server config > nor know its signing software, thus i can guess only, but IMO it comes > from exim -- i roughly remember that from some headers in past. > > By default exim (4.94) uses this list of headers to sign: > > > ...:List-Id:List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive > > That means, that exim signs all occurrences (not over sign) and > nonexistence of these headers. exim provides second list of headers, it > is exactly the same, but over signs all these headers, thus things are > the same (in this topic). That means that in both default cases, all > these headers are always included in signature. > > Try to guess how many exims uses one of these defaults? IMO, that will > not be negligible... I just went through and did a review of a few years of email to the PostgreSQL mailing lists and while it wasn't completely scientific (using grep mainly and not some proper processing), I found only two messages that arrived to any of the lists that I'm on (which is all the big ones and most of the others) that had a 'List.*' header in a 'h=' line and one of those was clearly a bit of spam that got through. Certainly doesn't seem to be a common issue. Thanks, Stephen signature.asc Description: PGP signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Mailing Lists and domains with DMARC reject
On Tue 07/Mar/2023 20:02:48 +0100 Slavko via mailop wrote: Dňa 7. marca 2023 17:36:17 UTC používateľ Alessandro Vesely via mailop napísal: Yeah, RFC4871 was a proposed standard, RFC6376, four years later became an Internet standard. Once there was a level in between... Seems that 4 years was not enough ;-) Or we understand idea behind that RFC wrongly... We seem to agree. But then, why does people sign Content-Transfer-Encoding:? Good question, but bad target ;-) But you can guess answer itself: how many people expect, that when 7bit is enough for them, it must be enough for all? Or another group of people who even don't know about transfer encoding at all... And we must not forget about Homo Copy&paste ;-) BTW, our Minister of Informatics have (had) own video on youtube, including notebook (to we all see that she is expert) and on notebook yellow sticker with (readable) password. What one can expect from that expert? Only that Mira2020 (or so) is by government approved password, which all have to use :-P I slightly lean toward the hypothesis of our understanding the idea behind that RFC wrongly, because, for example, John Levine, to name a mailopper who is neither a copycat nor a fake expert, does so. And why does RFC8058 require that fields such as List-Unsubscribe-Post: MUST be signed? Is it special "One click" case? I was not interested in it yet... Neither am I. I saw it because someone asked me to sign that field by default. I was surprised to see Section 4 saying: The List-Unsubscribe and List-Unsubscribe-Post headers MUST be covered by the signature and included in the "h=" tag of a valid DKIM-Signature header field. It was already discussed that the URL (presumably pointing to the same domain) must include an opaque token by which the target can check authenticity. IOW, signing gently allows greater flexibility, while signing heavily doesn't prevent replaying. We can define third group: sign carefully :-) But here i see one big problem. One have to select signed headers list on per message base, as what constructs core of message can differ for any message. My system is not prepared for that and i will guess that many other systems are the same. I use one domain for all types of messages, some even use same sender address for that. Guessing how/what to sign properly in that generic environment is near to impossible... The same applies to shared hostings (common for emails here). I'm thinking to add a third header field list. From OpenDKIM, I have requiredhdrs, which are the header fields to be signed /if they exist/. Then I have oversignhdrs, which are the ones to unconditionally append to h=. The third list would contain the fields to be signed once even if they don't exist. I'd put Subject:, To: and Cc: in the third list, for example. Do you have such settings? Why do you sign Content-Type: since you know it is going to be changed? Do you mean exactly me, or it was generic question? If you mean me: Do you want change the text/plain message, eg. to multipart/alternative with text/html appended? Of course, in my case that change will invalidate body signature too (as i sign whole body), but anyway, it constructs core of message, thus (IMO) fulfill RFC. Yes, I meant you, since you (are among the ones who) do it. The change to multipart can only happen using the deprecated l=. It allows to completely replace the body appearance. As you don't use l=, the only added protection is against an improbable collision between the original bh= and the hash of the modified body. When/where do you expect Content-Type change? What i miss? MLM wraps the MIME structure if you PGP-sign the message. Otherwise even if C-T is kept text/plain, it is rewritten without regard to the original. That is: Content-Type: text/plain; charset=utf-8 instead of: Content-Type: text/plain; charset=utf-8 It doesn't matter if canon is relaxed, but "UTF-8" would differ. Best Ale -- ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Mailing Lists and domains with DMARC reject
Hi, Dňa 7. marca 2023 17:36:17 UTC používateľ Alessandro Vesely via mailop napísal: >Yeah, RFC4871 was a proposed standard, RFC6376, four years later became an >Internet standard. Once there was a level in between... Seems that 4 years was not enough ;-) Or we understand idea behind that RFC wrongly... >We seem to agree. But then, why does people sign Content-Transfer-Encoding:? Good question, but bad target ;-) But you can guess answer itself: how many people expect, that when 7bit is enough for them, it must be enough for all? Or another group of people who even don't know about transfer encoding at all... And we must not forget about Homo Copy&paste ;-) BTW, our Minister of Informatics have (had) own video on youtube, including notebook (to we all see thet she is expert) and on notebook yellow sticker with (readable) password. What one can expect from that expert? Only that Mira2020 (or so) is by government approved password, which all havemto use :-P >And why does RFC8058 require that fields such as List-Unsubscribe-Post: MUST >be signed? Is it special "One click" case? I was not interested in it yet... >IOW, signing gently allows greater flexibility, while signing heavily doesn't >prevent replaying. We can define third group: sign carefuly :-) But here i see one big problem. One have to select signed headers list on per message base, as what constructs core of message can differ for any message. My system is not prepared for that and i will guess that many other systems are the same. I use one domain for all types of messages, some even use same sender address for that. Guessing how/what to sign properly in that generic environment is near to impossible... The same applies to shared hostings (common for emails here). >Why do you sign Content-Type: since you know it is going to be changed? Do you mean exactly me, or it was generic question? If you mean me: Do you want change the text/plain message, eg. to multipart/alternative with text/html appended? Of course, in my case that change will invalidate body signature too (as i sign whole body), but anyway, it constructs core of message, thus (IMO) fulfill RFC. When/where do you expect Content-Type change? What i miss? regards -- Slavko https://www.slavino.sk/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Mailing Lists and domains with DMARC reject
Hi, On Tue 07/Mar/2023 12:58:01 +0100 Slavko via mailop wrote: Dňa Tue, 7 Mar 2023 12:00:35 +0100 Alessandro Vesely via mailop napísal: The RFC was written at a time when there was not so much experience with DKIM and DMARC wasn't there. In that case, the RFC have to be in proposed state, until enough experiences are gathered. But we see it in many cases, quick, quick, to have at least something and problems we will solve later. But this latter either never happen or is near impossible then to apply and finally someone develop new standard (XKCD about this exists)... Yeah, RFC4871 was a proposed standard, RFC6376, four years later became an Internet standard. Once there was a level in between... Its Section 5.4.1 includes List-* fields, and unfortunately most guides refer to that section for guidance. No, it is not "list of headers", it is "list of examples of headers", it states: "The basic rule for choosing fields to include is to select those fields that constitute the "core" of the message content." If i remember properly, the exact list of headers was in some previous version RFC. This examples list has not MUST, nor SHOULD, nor anything other (except From header), it is just example... That i consider as good definition (for RFC), but many people want to have exact list (to not need to use own head), but one list cannot server all email purposes/usage. BTW, there is too: "Similarly, "In-Reply-To" and "References" might be desirable to include if one considers message threading to be a core part of the message." IMO exact case of many "normal" ML as this one, but not eg. for marketing "ML", where replies are not expected... Yes, you're right. RFC4871 said: The following header fields SHOULD be included in the signature, if they are present in the message being signed: That SHOULD was removed. If signatures are meant to protect the meaning of messages, rather than their hopping from a server to the next, only meaningful header fields should be signed and possibly oversigned. That is From:, Subject:, Author: if used, perhaps To:, Cc: and Reply-To: if they are considered significant. This more or less corresponds to the idea: "choose headers, which are important", and i understand RFC exactly in this mean. We seem to agree. But then, why does people sign Content-Transfer-Encoding:? And why does RFC8058 require that fields such as List-Unsubscribe-Post: MUST be signed? IMO, one have to oversign List-* headers only in case, that message have not be resend by (other) ML. But then particular ML rewrites From header and it becomes pointless, but in some "private/closed" ML can be desired. IOW, signing gently allows greater flexibility, while signing heavily doesn't prevent replaying. Someone should write a revised best practice. I agree! But again, here is as many email flows, that it cannot be published as RFC, as it will get neverending update flood and will be obsolete from start ;-) Agreed. Yet MAAWG or a similar organization could dig a bit more into the subject. To get X sign Y kind of guide. There must be some reason that escapes me why people sign heavy. Why do you sign Content-Type: since you know it is going to be changed? Only solution for this i see something as HTML is now, i name that (raw) "flying standard", without exact number and regularly updated :-) HTML is much more complicated. Common sense should be enough to decide what to sign. Best Ale -- ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Mailing Lists and domains with DMARC reject
Ahoj, Dňa Tue, 7 Mar 2023 12:00:35 +0100 Alessandro Vesely via mailop napísal: > The RFC was written at a time when there was not so much experience > with DKIM and DMARC wasn't there. In that case, the RFC have to be in proposed state, until enough experiences are gathered. But we see it in many cases, quick, quick, to have at least something and problems we will solve later. But this latter either never happen or is near impossible then to apply and finally someone develop new standard (XKCD about this exists)... > Its Section 5.4.1 includes List-* > fields, and unfortunately most guides refer to that section for > guidance. No, it is not "list of headers", it is "list of examples of headers", it states: "The basic rule for choosing fields to include is to select those fields that constitute the "core" of the message content." If i remember properly, the exact list of headers was in some previous version RFC. This examples list has not MUST, nor SHOULD, nor anything other (except From header), it is just example... That i consider as good definition (for RFC), but many people want to have exact list (to not need to use own head), but one list cannot server all email purposes/usage. BTW, there is too: "Similarly, "In-Reply-To" and "References" might be desirable to include if one considers message threading to be a core part of the message." IMO exact case of many "normal" ML as this one, but not eg. for marketing "ML", where replies are not expected... > If signatures are meant to protect the meaning of messages, rather > than their hopping from a server to the next, only meaningful header > fields should be signed and possibly oversigned. That is From:, > Subject:, Author: if used, perhaps To:, Cc: and Reply-To: if they are > considered significant. This more or less corresponds to the idea: "choose headers, which are important", and i understand RFC exactly in this mean. IMO, one have to oversign List-* headers only in case, that message have not be resend by (other) ML. But then particular ML rewrites From header and it becomes pointless, but in some "private/closed" ML can be desired. > Someone should write a revised best practice. I agree! But again, here is as many email flows, that it cannot be published as RFC, as it will get neverending update flood and will be obsolete from start ;-) Only solution for this i see something as HTML is now, i name that (raw) "flying standard", without exact number and regularly updated :-) regards -- Slavko https://www.slavino.sk pgpcaBBbv9MPW.pgp Description: Digitálny podpis OpenPGP ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Mailing Lists and domains with DMARC reject
On Tue 07/Mar/2023 09:51:31 +0100 Slavko via mailop wrote: IMO, the real problem comes, that there is not good description, when and which headers to sign and what are consequences, if one does this or this... The RFC is vague in that, but that is OK, as there are too many possibilities how messages can be constructed, but something as best practices is missing (or at least i am not aware of it). The RFC was written at a time when there was not so much experience with DKIM and DMARC wasn't there. Its Section 5.4.1 includes List-* fields, and unfortunately most guides refer to that section for guidance. If signatures are meant to protect the meaning of messages, rather than their hopping from a server to the next, only meaningful header fields should be signed and possibly oversigned. That is From:, Subject:, Author: if used, perhaps To:, Cc: and Reply-To: if they are considered significant. I'm unsure about References: and In-Reply-To:, is it forbidden to rearrange threads, maybe to avoid their drifting beyond the right margin? Someone should write a revised best practice. Best Ale -- ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Mailing Lists and domains with DMARC reject
Ahoj,
Dňa Mon, 6 Mar 2023 17:41:45 -0500 Stephen Frost via mailop
napísal:
> > I was interesting in this, thus i log DKIM signed headers list (not
> > from ML) for some weeks, oversigned List-* headers are not common,
> > but happens.
>
> I'm curious where it does happen and isn't actually from a mailing
> list.. The List-* header would presumably be empty in that case and
> yet still included in the signature? I realize it's possible but ...
> ugh.
I agree and i consider this as "ugh" too. IMO if message is not from ML
these headers does not construct core of message ;-)
Initially i noticed it in my job's email. I didn't see server config
nor know its signing software, thus i can guess only, but IMO it comes
from exim -- i roughly remember that from some headers in past.
By default exim (4.94) uses this list of headers to sign:
...:List-Id:List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive
That means, that exim signs all occurrences (not over sign) and
nonexistence of these headers. exim provides second list of headers, it
is exactly the same, but over signs all these headers, thus things are
the same (in this topic). That means that in both default cases, all
these headers are always included in signature.
Try to guess how many exims uses one of these defaults? IMO, that will
not be negligible...
My job's email is out of my full control (i can only enable/disable
DKIM) and it is managed by shared hosting company, thus i can guess
that all hosted domains will have the same settings. It is not big
hosting, but AFAIK number of domains is not small (for our country).
BTW, i use exim too, i tweak this headers list (beside others):
...:=List-Archive:=List-Id:...
The "=" means, sign (not over sign) these headers only if they are
presented in message. One can be even smarter and over sign header,
but only if if it is in message:
...{if def:h_List-Id: {:+List-Id}}...
In other words, it is configurable, but one have to do it ;-)
IMO, the real problem comes, that there is not good description, when
and which headers to sign and what are consequences, if one does this
or this... The RFC is vague in that, but that is OK, as there are too
many possibilities how messages can be constructed, but something as
best practices is missing (or at least i am not aware of it).
regards
--
Slavko
https://www.slavino.sk
pgpHITFo7DCvF.pgp
Description: Digitálny podpis OpenPGP
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
Re: [mailop] Mailing Lists and domains with DMARC reject
On Fri, Mar 3, 2023 at 10:07 AM Mark Fletcher via mailop wrote: > On Fri, Mar 3, 2023 at 9:21 AM Jesse Hathaway via mailop < > mailop@mailop.org> wrote: > >> >> 1. Rewrite the RFC5322.From address to be an address from the mailing >> list domain, place the original RFC5322.From address in the Reply-To >> header. Sign the message with the mailing list's DKIM key. >> >> This is what we do. > > 2. Preserve the original DKIM signing of the message by only adding >> additional headers, i.e. do not modify the subject or add a trailer >> message. >> >> This was never an option for us, as our users want a subject tag and > including a footer with an unsubscribe link is table stakes for a mailing > list. > There is a legal argument that is the best way to meet the various anti-spam laws... as in all things legal, there are a lot of different laws in different countries and one might make an argument that an unsubscribe header and button in mail clients would be sufficient... but making legal arguments to governments and courts is an expensive proposition with uncertain results, following the path of least resistance means less pain. Obviously, the liability is also very different for different senders/orgs... and also opt-in vs opt-out probably has some bearing as well, more technical users can handle opt-in better and hopefully unsubscribing... Brandon ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Mailing Lists and domains with DMARC reject
Greetings, * Slavko via mailop (mailop@mailop.org) wrote: > Dňa 3. marca 2023 17:03:35 UTC používateľ Jesse Hathaway via mailop > napísal: > >2. Preserve the original DKIM signing of the message by only adding > >additional headers, i.e. do not modify the subject or add a trailer > >message. This is what we do (for lists hosted on lists.postgresql.org). > This one will work only if sender doesn't oversigns List-* (or any other > added) headers, and some domains does it in regular mails... We've seen very very few (I'm not sure I specifically recally any..) List-* oversign cases. If we got those, I suspect we'd probably disable that user and ask them to try and fix their email system. > I was interesting in this, thus i log DKIM signed headers list (not from > ML) for some weeks, oversigned List-* headers are not common, but > happens. I'm curious where it does happen and isn't actually from a mailing list.. The List-* header would presumably be empty in that case and yet still included in the signature? I realize it's possible but ... ugh. * Mark Fletcher via mailop (mailop@mailop.org) wrote: > On Fri, Mar 3, 2023 at 9:21 AM Jesse Hathaway via mailop > wrote: > > 1. Rewrite the RFC5322.From address to be an address from the mailing > > list domain, place the original RFC5322.From address in the Reply-To > > header. Sign the message with the mailing list's DKIM key. > > This is what we do. Our users nearly rioted at this idea, for good reason, imv. > 2. Preserve the original DKIM signing of the message by only adding > > additional headers, i.e. do not modify the subject or add a trailer > > message. > > This was never an option for us, as our users want a subject tag and > including a footer with an unsubscribe link is table stakes for a mailing > list. Not being able to have an unsubscribe link is annoying but we've been pretty successful having a List-Unsubscribe header that a lot of mail clients recognize and will utilize to make a button to perform the unsub using. Getting that to happen on more would be interesting to us- if anyone has info about how to specifically do that, please feel free to pass that along. > > Does anyone have any knowledge on which methodology is the most > > successful for ensuring delivery. > > I can't tell you if #2 ensures better delivery, but even doing option #1 > gotchas abound. Many domains, regardless of DMARC policy, do not like it if > you send them an email with an RFC5322.From containing their own domain, > for example. All messages to Outlook 365 domains need their > Froms re-written. Many Exchange servers are set to silently drop messages > unless you re-write From lines. On several occasions I have considered just > re-writing ALL From lines, regardless of DMARC policy, but that is really > not wonderful and when asked, our users were against that idea. Only see one obvious office 365 user on our lists and their domain (as this would be domain specific, no..?) doesn't have a DMARC policy. That said, I do feel like we have pretty good delivery using approach #1. Admittedly, we aren't as big as others and our users are pretty technical. I'm fairly confident we deliver to a lot of exchange servers though successfully and looking at domains that end up delivered to outlook.com servers, there's certainly some with DMARC reject policy that we successfully deliver to without any rewriting of the RFC5322.From address. > It's a maze of twisty little passages... Indeed. > We have to keep a list of domains that require special re-writing, which is > updated by hand when people complain about deliverability issues. ... ew. Thanks, Stephen signature.asc Description: PGP signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Mailing Lists and domains with DMARC reject
On Fri, Mar 3, 2023 at 9:21 AM Jesse Hathaway via mailop wrote: > > 1. Rewrite the RFC5322.From address to be an address from the mailing > list domain, place the original RFC5322.From address in the Reply-To > header. Sign the message with the mailing list's DKIM key. > > This is what we do. 2. Preserve the original DKIM signing of the message by only adding > additional headers, i.e. do not modify the subject or add a trailer > message. > > This was never an option for us, as our users want a subject tag and including a footer with an unsubscribe link is table stakes for a mailing list. Does anyone have any knowledge on which methodology is the most > successful for ensuring delivery. > I can't tell you if #2 ensures better delivery, but even doing option #1 gotchas abound. Many domains, regardless of DMARC policy, do not like it if you send them an email with an RFC5322.From containing their own domain, for example. All messages to Outlook 365 domains need their Froms re-written. Many Exchange servers are set to silently drop messages unless you re-write From lines. On several occasions I have considered just re-writing ALL From lines, regardless of DMARC policy, but that is really not wonderful and when asked, our users were against that idea. It's a maze of twisty little passages... We have to keep a list of domains that require special re-writing, which is updated by hand when people complain about deliverability issues. Hope this helps. Mark ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Mailing Lists and domains with DMARC reject
Dňa 3. marca 2023 17:03:35 UTC používateľ Jesse Hathaway via mailop napísal: >2. Preserve the original DKIM signing of the message by only adding >additional headers, i.e. do not modify the subject or add a trailer >message. This one will work only if sender doesn't oversigns List-* (or any other added) headers, and some domains does it in regular mails... I was interesting in this, thus i log DKIM signed headers list (not from ML) for some weeks, oversigned List-* headers are not common, but happens. regards -- Slavko https://www.slavino.sk/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
