Re: [mailop] Mailing Lists and domains with DMARC reject

[Ángel via mailop]

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

[John R Levine via mailop]

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] delisting from Invaluement ivmURI

[Eric Cole via mailop]

Rob at Invaluement reached out to us directly.  He was able to provide details 
and we were able to resolve the issue.

Thank you for the quick response!

ERIC COLE

1-866-534-5465 (v)  |  404-567-4779 (f) 
www.entrustedmail.com

-Original Message-
From: mailop  On Behalf Of Atro Tossavainen via 
mailop
Sent: Wednesday, March 8, 2023 9:53 AM
To: mailop@mailop.org
Subject: Re: [mailop] delisting from Invaluement ivmURI

> One of our brand's domain has been listed on the Invaluement ivmURI RBL.

The operator is present here on Mailop. They should be waking up soonish - I 
can't remember where they are but there's a chance they're on the west coast 
and that would mean it's soon 5 am there.

--
Atro Tossavainen, Founder, Partner
Koli-Lõks OÜ (reg. no. 12815457, VAT ID EE101811635) Tallinn, Estonia tel. 
+372-5883-4269, 
https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.koliloks.eu%2F=05%7C01%7Cecole%40entrustedmail.com%7C92d30576493046e8356c08db1fe59312%7C9b18bc280df7444591f81f83d39e61fe%7C0%7C0%7C638138843117300053%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=va756xM0ZYUbGC90HNVthYb5jgxQNnO2rk6%2FFDtS8pQ%3D=0
___
mailop mailing list
mailop@mailop.org
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist.mailop.org%2Flistinfo%2Fmailop=05%7C01%7Cecole%40entrustedmail.com%7C92d30576493046e8356c08db1fe59312%7C9b18bc280df7444591f81f83d39e61fe%7C0%7C0%7C638138843117300053%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=s72eolr6yhbW7RvG1ryB1bpG1O84btgWSzlujzppfXg%3D=0
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] delisting from Invaluement ivmURI

[Rob McEwen via mailop]

Handled off-list. Sorry for the noise.
(btw - entrustedmail.com wasn't ever listed, it was another domain)
---Rob McEwen, invaluement



-- Original Message --

From "Eric Cole via mailop" 

To "mailop@mailop.org" 
Date 3/8/2023 7:03:56 AM
Subject [mailop] delisting from Invaluement ivmURI


Hello all,

One of our brand's domain has been listed on the Invaluement ivmURI 
RBL.


We have attempted to use the delisting process but to no avail as the 
domain is still listed listed nearly a day later.


This is causing an issue not just for those recipients who's mail 
filtering uses ivmURI as a blocklist, but also, apparently, for any 
O365 or Microsoft hosted email as the emails from our service are going 
to the spam/junk folders there.  I received an update on our Microsoft 
O365 ticket that our brand’s domain on ivmURI and that is currently the 
primary reason why these emails are endiung up in the spam/junk folder.


Is there anyone at Invaluement that could reach out to see what we can 
do to get delisted properly?


We have a secure message portal used by our customers.  The portal then 
generates a notification message to the recipient to log in and pick up 
the given message that was generated by one of our customers.


Thank you,



ERIC COLE


1-866-534-5465 (v)  |  404-567-4779 (f)
www.entrustedmail.com


___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Mailing Lists and domains with DMARC reject

[Slavko via mailop]

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

[Slavko via mailop]

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 

Re: [mailop] Mailing Lists and domains with DMARC reject

[Stephen Frost via mailop]

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] delisting from Invaluement ivmURI

[Atro Tossavainen via mailop]

> One of our brand's domain has been listed on the Invaluement ivmURI RBL.

The operator is present here on Mailop. They should be waking up
soonish - I can't remember where they are but there's a chance they're
on the west coast and that would mean it's soon 5 am there.

-- 
Atro Tossavainen, Founder, Partner
Koli-Lõks OÜ (reg. no. 12815457, VAT ID EE101811635)
Tallinn, Estonia
tel. +372-5883-4269, http://www.koliloks.eu/
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] delisting from Invaluement ivmURI

[Eric Cole via mailop]

Hello all,

One of our brand's domain has been listed on the Invaluement ivmURI RBL.

We have attempted to use the delisting process but to no avail as the domain is 
still listed listed nearly a day later.

This is causing an issue not just for those recipients who's mail filtering 
uses ivmURI as a blocklist, but also, apparently, for any O365 or Microsoft 
hosted email as the emails from our service are going to the spam/junk folders 
there.  I received an update on our Microsoft O365 ticket that our brand’s 
domain on ivmURI and that is currently the primary reason why these emails are 
endiung up in the spam/junk folder.

Is there anyone at Invaluement that could reach out to see what we can do to 
get delisted properly?

We have a secure message portal used by our customers.  The portal then 
generates a notification message to the recipient to log in and pick up the 
given message that was generated by one of our customers.

Thank you,

ERIC COLE
[cid:image001.png@01D9518C.23516B30]
1-866-534-5465 (v)  |  404-567-4779 (f)
www.entrustedmail.com

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Mailing Lists and domains with DMARC reject

[Alessandro Vesely via mailop]

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 ;-)

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