Re: [mailop] Mail Sending Self-Test Platform

[Taavi Eomäe via mailop]

On 03/03/2023 19:19, David Conrad via mailop wrote:
This kind of comment isn’t particularly useful as it appears to be a 
statement of an opinion with no explanation/justification.


DNSSEC is a different PKI. Like everything, it has pros and cons. 
Whether it is better or worse depends on what you’re looking at.


If you believe MTA-STS is superior, explaining why (ideally with data) 
would be useful.


To be totally fair the initial claim wasn't strongly backed either and 
it was late.


The general gist of it is indeed actually that DNSSEC is a different 
PKI, but it's still a PKI. There were been large problems with WebPKI 
that have now been remedied. The most recent being the rollout of 
Certificate Transparency. One can't say the same about DNSSEC's 
transparency.


Going back to the original statement that DANE is superior (or should 
supersede) MTA-STS, well, then DNSSEC should be a better PKI than WebPKI 
is. That is objectively not the case right now.


That is not to say MTA-STS is the absolute best and flawless, but it 
does currently offer more and come with fewer downsides than DANE would. 
This doesn't however mean there's no value in DNSSEC or DANE - here at 
Zone  we have adopted and implemented (for our 
customers) all three (DNSSEC, DANE and MTA-STS).


smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Mail Sending Self-Test Platform

[Grant Taylor via mailop]

On 3/2/23 12:27 PM, Tobias Fiebig via mailop wrote:

The tool looks for a perfect world, which there isn't. ...

Still, if i'd not deduct points for those things, everyone would get 
a 10. ;-)


I have no idea if your infrastructure / UI could support this or not, 
but what if you had an option to turn off / not count a test when 
displaying the results.


E.g. doesn't like lack of rDNS signing, so instead of saying 7 out of 8 
what if you said 7 out of 7* where the * means that some tests are 
disabled / ignored.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Mail Sending Self-Test Platform

[Grant Taylor via mailop]

On 2/28/23 2:51 PM, John Levine via mailop wrote:
It's not common and I would be astonished if anyone checked as part 
of delivery.


I wouldn't mind if the test called it out mostly in the sense that:
 - I would want case consistency
 - I'd be worried about tickling a bug in someone else's software / 
configuration thereof.


As such a polite heads up would be appreciated.



--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Mail Sending Self-Test Platform

[Tobias Fiebig via mailop]

Heho,
> Heh, it turns out that actually works, so not a big deal :-)
Not tooo sure; There were a lot of timeouting tests which looked like
'did not reload page'; Wouldn't be surprised if _some_ browsers are
fine with it, while others aren't. Anyway, for good measure, it's fixed
now. ;-)

And thanks again for finding it. :-)

With best regards,
Tobias
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Mail Sending Self-Test Platform

[Ángel via mailop]

On 2023-03-04 at 01:37 +0100, Tobias Fiebig via mailop wrote:
Heho,
> 
> On Fri, 2023-03-03 at 17:02 +0100, Ángel via mailop wrote:
> > Note you could use a  > for
> > a refresh-every-10-seconds functionality. (meta refresh could be
> > blocked as well, though)
> Briefly considered that; However, contrary to JS (which is often
> ignored by screenreaders) the HTML manual put a warning marker on
> that
> in terms of accessibility. So i decided to skip on that.

I suspect it wouldn't really matter, given the only point of that page
is to get periodically reloaded until content appears. I don't really
mind either way, though. It was just a comment


> > I was kinda surprised that whitespace was allowed here in
> > javascript,
> > btw: “window .location.reload();”
> 
> "ups"; Fix is in staging (along with a better description for reverse
> DNS being unsigned, making clear that signing that is more in the
> 'because we can' realm and "some _theoretical_ attacks".

Heh, it turns out that actually works, so not a big deal :-)


Regards


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

Re: [mailop] Mail Sending Self-Test Platform

[Tobias Fiebig via mailop]

Heho,

On Fri, 2023-03-03 at 17:02 +0100, Ángel via mailop wrote:
> Note you could use a  a refresh-every-10-seconds functionality. (meta refresh could be
> blocked as well, though)
Briefly considered that; However, contrary to JS (which is often
ignored by screenreaders) the HTML manual put a warning marker on that
in terms of accessibility. So i decided to skip on that.

> I was kinda surprised that whitespace was allowed here in javascript,
> btw: “window .location.reload();”

"ups"; Fix is in staging (along with a better description for reverse
DNS being unsigned, making clear that signing that is more in the
'because we can' realm and "some _theoretical_ attacks". 

Also currently setting up an open v6 only resolver that will be
referenced for v6 only resolution. ;-)

With best regards,
Tobias


-- 
Dr.-Ing. Tobias Fiebig
T +31 616 80 98 99
M tob...@fiebig.nl

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

Re: [mailop] Mail Sending Self-Test Platform

[David Conrad via mailop]

This kind of comment isn’t particularly useful as it appears to be a statement 
of an opinion with no explanation/justification.

DNSSEC is a different PKI. Like everything, it has pros and cons. Whether it is 
better or worse depends on what you’re looking at.

If you believe MTA-STS is superior, explaining why (ideally with data) would be 
useful.

Regards,
-drc

> On Mar 3, 2023, at 2:14 AM, Taavi Eomäe via mailop  wrote:
> 
> You make the strong assumption that DNSSEC is a better PKI than WebPKI.
> 
> It is not, it's significantly worse. MTA-STS would be inferior if DNSSEC was 
> good, it is not good.
> 
> 
> 
> 
> 
> On 02/03/2023 22:23, Tom Ivar Helbekkmo via mailop wrote:
>> Tobias Fiebig   writes:
>> 
>>> I share your sentiment. I am not a fan of MTA-STS, and honestly not
>>> really sure which problem it solves.
>> I'm reasonably sure.  The problem is: "people are starting to want DANE,
>> which means we need to implement DNSSEC, which will cost us money, so we
>> need to design an inferior mechanism that won't cost us anything, but
>> will fool people into thinking it's close enough to the real thing".
>> 
>> Heck, it evens says so in the RFC itself, if you read it carefully.
>> 
>> -tih
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop



signature.asc
Description: Message signed with OpenPGP
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Mail Sending Self-Test Platform

[Ángel via mailop]

On 2023-02-27 at 12:59 +0100, Tobias Fiebig via mailop wrote:
> Please note that setting up the tests (as we have to configure vhosts
> for some MTA-STS cases etc.) takes some time on our site. The test-
> site should periodically reload and provide the status. As we use JS
> for that part, please reload it manually every few minutes if you
> block JS.

Note you could use a https://list.mailop.org/listinfo/mailop

Re: [mailop] Mail Sending Self-Test Platform

[Bill Cole via mailop]

On 2023-03-03 at 02:58:18 UTC-0500 (Fri, 3 Mar 2023 08:58:18 +0100)
Alessandro Vesely via mailop 
is rumored to have said:


On Thu 02/Mar/2023 20:52:40 +0100 Bill Cole via mailop wrote:
On 2023-03-02 at 12:53:34 UTC-0500 (Thu, 2 Mar 2023 17:53:34 + 
(UTC))

L. Mark Stone via mailop 
is rumored to have said:

We got a ding on our DNSSEC score, because the PTR record isn't 
signed. Is this really as big an issue as the explanatory test makes 
out?


No. It isn't ANYTHING.



Yet, reverse DNS is still considered a very important security 
indicator for a number of services.


It's a clue, not reliable information. Never has been. In a world where 
MS cannot reliably keep the As and PTRs of their outbound mail servers 
consistent, a signature on a PTR can't be considered important.


--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Mail Sending Self-Test Platform

[Tobias Fiebig via mailop]

Heho,

no, i at least make the assumption that the people who get themselves
to implement MTA-STS (in either direction) will also have PKIX valid
certs.

And that group of orgs is relatively small. 

In contrast, you can, e.g., just enable dane for you N-thousand
customers by adding records to _your_ MXes.

But, as said some years ago when i first complained about this: I
wasn't there to give this input when it was spec'ed; So my complaining
now also has _some_ limits. ;-)

With best regards,
Tobias
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Mail Sending Self-Test Platform

[Taavi Eomäe via mailop]

You make the strong assumption that DNSSEC is a better PKI than WebPKI.

It is not, it's significantly worse. MTA-STS *would* be inferior if 
DNSSEC was good, it is not good.




On 02/03/2023 22:23, Tom Ivar Helbekkmo via mailop wrote:

Tobias Fiebig  writes:


I share your sentiment. I am not a fan of MTA-STS, and honestly not
really sure which problem it solves.

I'm reasonably sure.  The problem is: "people are starting to want DANE,
which means we need to implement DNSSEC, which will cost us money, so we
need to design an inferior mechanism that won't cost us anything, but
will fool people into thinking it's close enough to the real thing".

Heck, it evens says so in the RFC itself, if you read it carefully.

-tih

smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Mail Sending Self-Test Platform

[Tom Ivar Helbekkmo via mailop]

Chris Adams via mailop  writes:

> Since POSIX has nothing to do with network communication protocols for
> email, that's a funny hill to die on.  The RFC defines the response
> format, which doesn't have to be a text file on a POSIX system at all
> (could be generated on the fly, could be on a non-POSIX system).

You're right, of course.  I'm conflating text files with text protocols.

-tih
-- 
Most people who graduate with CS degrees don't understand the significance
of Lisp.  Lisp is the most important idea in computer science.  --Alan Kay
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Mail Sending Self-Test Platform

[Alessandro Vesely via mailop]

On Thu 02/Mar/2023 20:52:40 +0100 Bill Cole via mailop wrote:

On 2023-03-02 at 12:53:34 UTC-0500 (Thu, 2 Mar 2023 17:53:34 + (UTC))
L. Mark Stone via mailop 
is rumored to have said:

We got a ding on our DNSSEC score, because the PTR record isn't signed. Is 
this really as big an issue as the explanatory test makes out?


No. It isn't ANYTHING.



Yet, reverse DNS is still considered a very important security indicator for a 
number of services.



Best
Ale
--





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

Re: [mailop] Mail Sending Self-Test Platform

[Chris Adams via mailop]

Once upon a time, Tom Ivar Helbekkmo  said:
> Tobias Fiebig via mailop  writes:
> > If I read RFC8461 correctly, this is not required for MTA-STS policies:
> 
> Until they formally override POSIX, they have to abide by it.

Since POSIX has nothing to do with network communication protocols for
email, that's a funny hill to die on.  The RFC defines the response
format, which doesn't have to be a text file on a POSIX system at all
(could be generated on the fly, could be on a non-POSIX system).

-- 
Chris Adams 
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Mail Sending Self-Test Platform

[Tom Ivar Helbekkmo via mailop]

Tobias Fiebig via mailop  writes:

> If I read RFC8461 correctly, this is not required for MTA-STS policies:

Until they formally override POSIX, they have to abide by it.

-tih
-- 
Most people who graduate with CS degrees don't understand the significance
of Lisp.  Lisp is the most important idea in computer science.  --Alan Kay
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Mail Sending Self-Test Platform

[Tom Ivar Helbekkmo via mailop]

Tobias Fiebig via mailop  writes:

> If I read RFC8461 correctly, this is not required for MTA-STS policies:

...begging the question whether MTA-STS is ever even interesting.

-tih
-- 
Most people who graduate with CS degrees don't understand the significance
of Lisp.  Lisp is the most important idea in computer science.  --Alan Kay
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Mail Sending Self-Test Platform

[Tom Ivar Helbekkmo via mailop]

Tobias Fiebig  writes:

> I share your sentiment. I am not a fan of MTA-STS, and honestly not
> really sure which problem it solves.

I'm reasonably sure.  The problem is: "people are starting to want DANE,
which means we need to implement DNSSEC, which will cost us money, so we
need to design an inferior mechanism that won't cost us anything, but
will fool people into thinking it's close enough to the real thing".

Heck, it evens says so in the RFC itself, if you read it carefully.

-tih
-- 
Most people who graduate with CS degrees don't understand the significance
of Lisp.  Lisp is the most important idea in computer science.  --Alan Kay
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Mail Sending Self-Test Platform

[Bill Cole via mailop]

On 2023-03-02 at 15:11:25 UTC-0500 (Thu, 02 Mar 2023 21:11:25 +0100)
Tobias Fiebig via mailop 
is rumored to have said:

> I share your sentiment. I am not a fan of MTA-STS, and honestly not
> really sure which problem it solves.

It solves Google's problem of not wanting to deploy DNSSEC.

-- 
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Mail Sending Self-Test Platform

[Tobias Fiebig via mailop]

Heho,
> If I recall correctly, POSIX says that a line of text is not a line
> of text unless it ends in a proper line ending marker.  I'm unsure of
> the details, here, but I am sure that when, a few years ago, I dug
> deeply into this, I concluded that the last line of a UNIX text file
> absolutely has to end with an LF for the line to be unequivocally
> part of the file.

If I read RFC8461 correctly, this is not required for MTA-STS policies:

RFC8461, Sec. 3.2.
> sts-policy-record= sts-policy-field *WSP
>*(sts-policy-term sts-policy-field *WSP)
>[sts-policy-term]

;-)

With best regards,
Tobias
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Mail Sending Self-Test Platform

[Tom Ivar Helbekkmo via mailop]

Tobias Fiebig via mailop  writes:

> Besides: The CRLF thing is actually a bit funny; The RFC iirc just says
> 'delimited by', so i am not too sure whether it really must be at the
> end of the file; And then there is an errata clarifying that you can
> also delimit with LF instead of CRLF as mentioned in the RFC.

If I recall correctly, POSIX says that a line of text is not a line of
text unless it ends in a proper line ending marker.  I'm unsure of the
details, here, but I am sure that when, a few years ago, I dug deeply
into this, I concluded that the last line of a UNIX text file absolutely
has to end with an LF for the line to be unequivocally part of the file.

-tih
-- 
Most people who graduate with CS degrees don't understand the significance
of Lisp.  Lisp is the most important idea in computer science.  --Alan Kay
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Mail Sending Self-Test Platform

[Tobias Fiebig via mailop]

Heho,
> ...and now it gives me 9 out of 10, acknowledging that my MTA
> verifies DNSSEC and honors TLSA records.
My own domain (and the sending for email-security-scans.org) scores
9/10 as well; Mostly because OpenSMTPd lacks DANE and MTA-STS
validation... and TLS-RPT sending... that is a whole nother beast.

> Of course, I'll never get a 10 out of 10.  I'll implement TLS
> reports, by and by, but MTA-STS will be supported here over my dead
> body.  :)
I share your sentiment. I am not a fan of MTA-STS, and honestly not
really sure which problem it solves.

> This is the most impressive email testing system I've ever seen.
Thanks. The todo is still long, and the code bad. ;-) But i am trying 
to get it into a robust state; It can be rather surprising how emails
look in the wild.

Newest find: Bump message storage in the DB from BLOB to LONGBLOB, 
because apparently there are 167KB(!) bounces these days... size 
mostly added by the NDR. -.-'

With best regards,
Tobias 
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Mail Sending Self-Test Platform

[Tom Ivar Helbekkmo via mailop]

Tom Ivar Helbekkmo via mailop  writes:

> I'll give it another go tonight, then!  :)

...and now it gives me 9 out of 10, acknowledging that my MTA verifies
DNSSEC and honors TLSA records.

Of course, I'll never get a 10 out of 10.  I'll implement TLS reports,
by and by, but MTA-STS will be supported here over my dead body.  :)

This is the most impressive email testing system I've ever seen.

-tih
-- 
Most people who graduate with CS degrees don't understand the significance
of Lisp.  Lisp is the most important idea in computer science.  --Alan Kay
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Mail Sending Self-Test Platform

[Bill Cole via mailop]

On 2023-03-02 at 12:53:34 UTC-0500 (Thu, 2 Mar 2023 17:53:34 + 
(UTC))

L. Mark Stone via mailop 
is rumored to have said:

We got a ding on our DNSSEC score, because the PTR record isn't 
signed. Is this really as big an issue as the explanatory test makes 
out?


No. It isn't ANYTHING.

--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Mail Sending Self-Test Platform

[Tobias Fiebig via mailop]

Hello Mark,
> We got a ding on our DNSSEC score, because the PTR record isn't
> signed.  Is this really as big an issue as the explanatory test makes
> out?
The tool looks for a perfect world, which there isn't. Un-signed rDNS
is not really a bad thing (of course, a hypothetical attacker could
temper with your rDNS to make fcrDNS fail to get your mails rejected...
but that is erm... "mildly unlikely".)

Still, if i'd not deduct points for those things, everyone would get a
10. ;-)


> We also got a ding on our MTA-STS record,
> but https://esmtp.email/tools/mta-sts/ said the only problem is a
> missing CRLF at the end of our txt file; easy enough to fix.  This
> tool however just said that our system doesn't support MTA-STS.
>  After I add the CRLF I'll rerun the test; if it still fails, I'll
> report back.
Actually... you did not get anything for your MTA-STS record, because
we're not testing that. You got that for your validation of and
adherence to MTA-STS policies when _sending_ mails.

I.e.: You don't validate/follow _our_ MTA-STS policy when sending
emails.

Besides: The CRLF thing is actually a bit funny; The RFC iirc just says
'delimited by', so i am not too sure whether it really must be at the
end of the file; And then there is an errata clarifying that you can
also delimit with LF instead of CRLF as mentioned in the RFC.

With best regards,
Tobias
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Mail Sending Self-Test Platform

[L. Mark Stone via mailop]

Thanks for this tool, which I just ran. 

We don't support IPv6, which were pretty much all of our bad scores, so not 
bothered. 

We got a ding on our DNSSEC score, because the PTR record isn't signed. Is this 
really as big an issue as the explanatory test makes out? 

"Some names needed for email delivery are not DNSSEC signed. This is important 
to verify the authenticity and integrity of the SPF, DKIM and DMARC entries." 

Our cluster is hosted on AWS; we really have no control over whether they sign 
PTR records for their IPs. 

Thoughts? 

We also got a ding on our MTA-STS record, but [ 
https://esmtp.email/tools/mta-sts/ | https://esmtp.email/tools/mta-sts/ ] said 
the only problem is a missing CRLF at the end of our txt file; easy enough to 
fix. This tool however just said that our system doesn't support MTA-STS. After 
I add the CRLF I'll rerun the test; if it still fails, I'll report back. 

Thanks again for this testing tool! 
Mark 

P.S. We also got a ding on our MTA-STS record, but [ 
https://esmtp.email/tools/mta-sts/ | https://esmtp.email/tools/mta-sts/ ] said 
that's due to a missing CRLF at the end of our txt file; easy enough to fix. 
_ 
L. Mark Stone, Founder 
North America's Leading Zimbra VAR/BSP/Training Partner 
For Companies With Mission-Critical Email Needs 


From: "Laura Atkins via mailop"  
To: "Gellner, Oliver via mailop"  
Sent: Thursday, March 2, 2023 12:38:52 PM 
Subject: Re: [mailop] Mail Sending Self-Test Platform 





On 1 Mar 2023, at 16:21, John R Levine via mailop  wrote: 


BQ_BEGIN
Still, i am a bit wondering; Looking at the data flushed in so far (and 
already multiple bugs filed against implementations)... there are a lot 
of funny milters and often unmaintained software integrated in funny 
docker stacks (probably preaching to the choir there, but i have a lot 
of grievances with those setups), and generally a lot of awry things 
(example.com. IN TXT "v=spf1 include:example.com -all" is, for example, 
far more common than i'd have ever believed...). 



In the DMARC working group we've had endless arguments about what changes will 
or won't break existing DMARC setups, informed by a lot of opinions and very 
little data. Actual data would be greatly appreciated. 

It's not surprising that there are a lot of broken DMARC and SPF records. The 
question is whether anyone cares. My impression is that in many cases there was 
a checklist item "DMARC" so someone did the absolute mimimum. A p=none policy, 
a sloppy SPF record, and no DKIM is a strong hint. 

BQ_END

Likewise, there are countless folks out there recommending implement DMARC for 
every deliverability problem (with absolutely zero recommendations as to what 
that means). There are also soom EXTREMELY broken SaaS providers who have 
instructions for that say: publish this DKIM key in your DNS, publish this 
DMARC record and publish this SPF record - while the SaaS provider uses none of 
the customer domains anywhere in the mail. 

Additionally, there are scammers out there hunting for bug bounties using “your 
domain is at risk due to a lack of DMARC record, how much will you pay me for 
letting you know?” 

laura 

-- 
The Delivery Experts 

Laura Atkins 
Word to the Wise 
la...@wordtothewise.com 

Email Delivery Blog: http://wordtothewise.com/blog 







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

Re: [mailop] Mail Sending Self-Test Platform

[Laura Atkins via mailop]

> On 1 Mar 2023, at 16:21, John R Levine via mailop  wrote:
> 
>> Still, i am a bit wondering; Looking at the data flushed in so far (and
>> already multiple bugs filed against implementations)... there are a lot
>> of funny milters and often unmaintained software integrated in funny
>> docker stacks (probably preaching to the choir there, but i have a lot
>> of grievances with those setups), and generally a lot of awry things
>> (example.com. IN TXT "v=spf1 include:example.com -all" is, for example,
>> far more common than i'd have ever believed...).
> 
> In the DMARC working group we've had endless arguments about what changes 
> will or won't break existing DMARC setups, informed by a lot of opinions and 
> very little data.  Actual data would be greatly appreciated.
> 
> It's not surprising that there are a lot of broken DMARC and SPF records. The 
> question is whether anyone cares.  My impression is that in many cases there 
> was a checklist item "DMARC" so someone did the absolute mimimum.  A p=none 
> policy, a sloppy SPF record, and no DKIM is a strong hint.

Likewise, there are countless folks out there recommending implement DMARC for 
every deliverability problem (with absolutely zero recommendations as to what 
that means). There are also soom EXTREMELY broken SaaS providers who have 
instructions for that say: publish this DKIM key in your DNS, publish this 
DMARC record and publish this SPF record - while the SaaS provider uses none of 
the customer domains anywhere in the mail. 

Additionally, there are scammers out there hunting for bug bounties using “your 
domain is at risk due to a lack of DMARC record, how much will you pay me for 
letting you know?”  

laura 

-- 
The Delivery Experts

Laura Atkins
Word to the Wise
la...@wordtothewise.com 

Email Delivery Blog: http://wordtothewise.com/blog  






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

Re: [mailop] Mail Sending Self-Test Platform

[Tom Ivar Helbekkmo via mailop]

Tobias Fiebig  writes:

> the 'issue' was indeed that you moved the addresses to Cc: instead of
> To:; Us not checking there is actually somewhat of an oversight.

Aha!  That's my MUA doing that, of course.  I handle email with Gnus.

> Fixed and pushed.

I'll give it another go tonight, then!  :)

-tih
-- 
Most people who graduate with CS degrees don't understand the significance
of Lisp.  Lisp is the most important idea in computer science.  --Alan Kay
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Mail Sending Self-Test Platform

[Tobias Fiebig via mailop]

Heho,

the 'issue' was indeed that you moved the addresses to Cc: instead of
To:; Us not checking there is actually somewhat of an oversight.

Fixed and pushed.

With best regards,
Tobias

On Thu, 2023-03-02 at 09:13 +0100, Tom Ivar Helbekkmo wrote:
> Tobias Fiebig via mailop  writes:
> 
> > If you try this again tomorrow you have to start a new test, as
> > tests
> > that do not receive a reply within an hour get removed (minimizing
> > data
> > storage etc.)
> 
> I just did - same results, and test ID is
> gq7oj8xk44aw452j4e4fzf7vhpu4v3.
> 
> -tih

-- 
Dr.-Ing. Tobias Fiebig
T +31 616 80 98 99
M tob...@fiebig.nl

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

Re: [mailop] Mail Sending Self-Test Platform

[Tom Ivar Helbekkmo via mailop]

Tobias Fiebig via mailop  writes:

> If you try this again tomorrow you have to start a new test, as tests
> that do not receive a reply within an hour get removed (minimizing data
> storage etc.)

I just did - same results, and test ID is gq7oj8xk44aw452j4e4fzf7vhpu4v3.

-tih
-- 
Most people who graduate with CS degrees don't understand the significance
of Lisp.  Lisp is the most important idea in computer science.  --Alan Kay
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Mail Sending Self-Test Platform

[Tobias Fiebig via mailop]

Heho,
> Will do - have been waiting for the web site to send me another mail
> for a while, now, but it seems I'll have to leave it until morning. 
> I'm guessing it's rather busy, with lots of people wanting to try it?
Gnah... seems like i got ratelimited at LE's staging environment for
(somewhat good) reasons; Hot fixed it for now and will migrate to a
self-signed cert later. (It _would_ be cool to have actually valid LE
certs to properly test MTA-STS rpt sending; But then again...
unlikely).

If you try this again tomorrow you have to start a new test, as tests
that do not receive a reply within an hour get removed (minimizing data
storage etc.)
> 

> It's Firefox.
Hrm, will give that a shot later, iirc the fonts should come with the
site.

With best regards,
Tobias

-- 
Dr.-Ing. Tobias Fiebig
T +31 616 80 98 99
M tob...@fiebig.nl

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

Re: [mailop] Mail Sending Self-Test Platform

[Tom Ivar Helbekkmo via mailop]

Tobias Fiebig via mailop  writes:

> If you'd like to look into this a bit more, could you maybe run another
> test, but check the box for 'store my emails'?

Will do - have been waiting for the web site to send me another mail for
a while, now, but it seems I'll have to leave it until morning.  I'm
guessing it's rather busy, with lots of people wanting to try it?

> Will see if something can be done to make this render well on netbsd
> as well. Which browser are you using?  w3m/links(2) with fb rendering
> or something with a gui?

It's Firefox.

-tih
-- 
Most people who graduate with CS degrees don't understand the significance
of Lisp.  Lisp is the most important idea in computer science.  --Alan Kay
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Mail Sending Self-Test Platform

[Tobias Fiebig via mailop]

Heho,

> My system has five mail items still queued, that won't be delivered.
> Two because of broken DNSSEC, three because of invalid TLSA records.
> (It's report ppk95bat9arnakovq5nmljen4n342u, by the way.)
> 
> The consequences of this in the report could be somewhat confusing. 
> It says "Not all DANE related emails have been sent; We are lacking
> information to analyze DANE support.", and "The DNS resolver your
> email provider/server relies on, Mail for DNSSEC enabled DNS
> Resolution tests not sent; Cannot assess test. DNSSEC."  That sounds
> like something is wrong, but there really isn't, if I understand this
> correctly; you just don't have the responses that would have told you
> that my system sent you something when it shouldn't have. 
Hrm, this depends on how you sent the emails; What we do to establish
if an email to a measurement target address (see detail page) has been
sent is check all To: addresses in each email we receive. Technically,
all 29 measurement destinations should be in the To: header of all
measurement mails. 

Specific emails not arriving is actually the signal we use to
determine, e.g., DNSSEC support. But we added the To: check to
distinguish between 'DNSSEC used' and 'specific mail not sent'.

You did not check 'store my emails', though, so i cannot check how you
did it for your test. I'd suspect something along the lines of 'one
mail with one To: per measurement destination'?

If you'd like to look into this a bit more, could you maybe run another
test, but check the box for 'store my emails'?


> (Also, I think maybe that last quote needs rewording - looks like
> it's missing one or more words?)
Yeah, good catch, fixing in a second.

> Further, all the nice little icons on the report page are Unicode
> characters, which works fine on Linux, and probably Windows, but on
> my workstation, which runs NetBSD, I don't have whatever font that
> is, so I just get those little boxes with the Unicode code point
> numbers in them. I guess actual graphics would be more portably
> rendered.
Given the high portion of the measurement setup running on BSD, this is
somewhat embarrassing. ;-) I would have expected the specific fonts to
be delivered with the site. (UI stuff is somewhat difficult... and "not
my core-strength". Will see if something can be done to make this
render well on netbsd as well. Which browser are you using?
w3m/links(2) with fb rendering or something with a gui?

With best regards,
Tobias

-- 
Dr.-Ing. Tobias Fiebig
T +31 616 80 98 99
M tob...@fiebig.nl

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

Re: [mailop] Mail Sending Self-Test Platform

[John Levine via mailop]

It appears that John R Levine via mailop  said:
>It's not surprising that there are a lot of broken DMARC and SPF records. 
>The question is whether anyone cares.  My impression is that in many cases 
>there was a checklist item "DMARC" so someone did the absolute mimimum.  A 
>p=none policy, a sloppy SPF record, and no DKIM is a strong hint.

Oops, p=reject even though it's SPF only. I've run into a bunch of US
government agencies that have done that.

R's,
John
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Mail Sending Self-Test Platform

[Tom Ivar Helbekkmo via mailop]

Tobias Fiebig via mailop  writes:

> https://email-security-scans.org/

Nice!  A couple of comments, though:

My system has five mail items still queued, that won't be delivered.
Two because of broken DNSSEC, three because of invalid TLSA records.
(It's report ppk95bat9arnakovq5nmljen4n342u, by the way.)

The consequences of this in the report could be somewhat confusing.  It
says "Not all DANE related emails have been sent; We are lacking
information to analyze DANE support.", and "The DNS resolver your email
provider/server relies on, Mail for DNSSEC enabled DNS Resolution tests
not sent; Cannot assess test. DNSSEC."  That sounds like something is
wrong, but there really isn't, if I understand this correctly; you just
don't have the responses that would have told you that my system sent
you something when it shouldn't have.  (Also, I think maybe that last
quote needs rewording - looks like it's missing one or more words?)

Further, all the nice little icons on the report page are Unicode
characters, which works fine on Linux, and probably Windows, but on my
workstation, which runs NetBSD, I don't have whatever font that is, so I
just get those little boxes with the Unicode code point numbers in them.
I guess actual graphics would be more portably rendered.

-tih
-- 
Most people who graduate with CS degrees don't understand the significance
of Lisp.  Lisp is the most important idea in computer science.  --Alan Kay
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Mail Sending Self-Test Platform

[John R Levine via mailop]

Still, i am a bit wondering; Looking at the data flushed in so far (and
already multiple bugs filed against implementations)... there are a lot
of funny milters and often unmaintained software integrated in funny
docker stacks (probably preaching to the choir there, but i have a lot
of grievances with those setups), and generally a lot of awry things
(example.com. IN TXT "v=spf1 include:example.com -all" is, for example,
far more common than i'd have ever believed...).


In the DMARC working group we've had endless arguments about what changes 
will or won't break existing DMARC setups, informed by a lot of opinions 
and very little data.  Actual data would be greatly appreciated.


It's not surprising that there are a lot of broken DMARC and SPF records. 
The question is whether anyone cares.  My impression is that in many cases 
there was a checklist item "DMARC" so someone did the absolute mimimum.  A 
p=none policy, a sloppy SPF record, and no DKIM is a strong hint.


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] Mail Sending Self-Test Platform

[Tobias Fiebig via mailop]

Heho,

On Tue, 2023-02-28 at 22:21 -0500, John Levine wrote:
> We briefly considered that and decided against it because the vast
> majority of actual DMARC records will continue to work unchanged, and
> long experience says that if you try to change the version number,
> you end up living with the old and new versions forever.
Yeah; Maybe it's time for an RFC for next month only containing "All
IETF created protocols MUST not have a numbered version indicator."
(This is (only partially) joking; But i somehow feel like there will
never be DKIMv2, STSv2, or TLSRPTv2 ;-)) 


> Remember that unknown tags are now ignored. In practice pct turned
> out to be impossible to implement so most people didn't try. The
> required->recommended for p= is to make it consistent with the
> _report._dmarc records in section 7.1 of RFC 7489.
Hm, yeah, and introduced tags should not be an issue as per 7489
already.

Still, i am a bit wondering; Looking at the data flushed in so far (and
already multiple bugs filed against implementations)... there are a lot
of funny milters and often unmaintained software integrated in funny
docker stacks (probably preaching to the choir there, but i have a lot
of grievances with those setups), and generally a lot of awry things
(example.com. IN TXT "v=spf1 include:example.com -all" is, for example,
far more common than i'd have ever believed...).

Then again, considering how bad _my_ code usually is... i am not too
sure how well many of those libs hold up towards change.

Point being, it might be interesting to conduct a structured study into
how different implementations in different versions handle DMARC
policies with different levels of 'errors' to inform this. I have a
colleague who might still have a lab-setup of implementations around,
to see if they could quickly do that.

With that information, i could then also provide a better score for
DMARC parsing, i.e., make a statement on like "current policy would
validate in $list_of_common_implementations but not in
$hopefully_short_list_of_other_implementations".

With best regards,
Tobias

-- 
Dr.-Ing. Tobias Fiebig
T +31 616 80 98 99
M tob...@fiebig.nl

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

Re: [mailop] Mail Sending Self-Test Platform

[John Levine via mailop]

It appears that Tobias Fiebig via mailop  said:
>John: Btw, what I am wondering; Given the last par of 6.3 in 7489,
>shouldn't dmarcbis switch to DMARC2, given that there are changes to
>existing tags ..

We briefly considered that and decided against it because the vast
majority of actual DMARC records will continue to work unchanged, and
long experience says that if you try to change the version number, you
end up living with the old and new versions forever.

(REQUIRED -> RECOMMENDED for p, removal of pct, rf, and
>ri), or does that not constitute a change? (Quick thought; Pretty sure
>there is a mail-thread on the list, though; Will dig through that
>later.)

Remember that unknown tags are now ignored. In practice pct turned out
to be impossible to implement so most people didn't try. The
required->recommended for p= is to make it consistent with the
_report._dmarc records in section 7.1 of RFC 7489.

R's,
John
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Mail Sending Self-Test Platform

[Tobias Fiebig via mailop]

Heho,
> It's in RFC 9091 and in the DMARC update currently in draft form at
> the IETF.  The intention was always that you could put private
> clauses in DMARC records which get ignored by clients that don't
> understand them, but the ABNF was overly clever.  That's fixed in the
> new draft too.

Hrm, digging through this; dmarcbis-27 now; Indeed there are some
interesting changes; Implementing this will take some time. Also, given
key differences in record parsing (esp. the MUST in -27 2nd to last
par. of 5.3, vs. SHOULD same place in 6.3 of 7489) might have
interesting implications re: behavior in real world systems, esp. when
looking at the long tail of 'mail-in-a-docker-ish' setups glued
together with curl | sudo bash.

I guess what i will do (with a bit more time) is actually implement
both interpretations to policy parsing (7489 as written, not as
intended vs. dmarcbis-27) with scoring being at one-passing-is-enough.

John: Btw, what I am wondering; Given the last par of 6.3 in 7489,
shouldn't dmarcbis switch to DMARC2, given that there are changes to
existing tags (REQUIRED -> RECOMMENDED for p, removal of pct, rf, and
ri), or does that not constitute a change? (Quick thought; Pretty sure
there is a mail-thread on the list, though; Will dig through that
later.)

With best regards,
Tobias
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Mail Sending Self-Test Platform

[Tobias Fiebig via mailop]

Heho,
On Tue, 2023-02-28 at 17:53 -0500, John R Levine wrote:
> > dmarcv1 is a typo in the description (i correctly check for DMARC1,
> > otherwise this would have shown up earlier);
> ??
> 
er... DKIMv1... -.-' The check checks for v=DMARC1, not DKIMv1 as the
description implies; Currently fixing that.


> It's in RFC 9091 and in the DMARC update currently in draft form at
> the IETF.  The intention was always that you could put private
> clauses in DMARC records which get ignored by clients that don't
> understand them, but the ABNF was overly clever.  That's fixed in the
> new draft too.
Will fix that part asap/tonight; Will let you know if it should behave
better.


With best regards,
Tobias
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Mail Sending Self-Test Platform

[John R Levine via mailop]

dmarcv1 is a typo in the description (i correctly check for DMARC1,
otherwise this would have shown up earlier);

??

The actual complaint is psd=n; Lemme see if i can make the report more
clear re: where it complained.

Do you maybe have some context on psd=n? I can't find it in 7489.


It's in RFC 9091 and in the DMARC update currently in draft form at the 
IETF.  The intention was always that you could put private clauses in 
DMARC records which get ignored by clients that don't understand them, but 
the ABNF was overly clever.  That's fixed in the new draft too.





With best regards,
Tobias

On Tue, 2023-02-28 at 17:32 -0500, John Levine wrote:

It appears that Tobias Fiebig via mailop  said:

Heho,

after our paper on mail sending configurations some time ago [1],
we
now glued that together into a self-service site:

https://email-security-scans.org/

I'd be happy to hear your feedback, especially if things do not
work as
expected (then, your test ID and ideally stored emails would be
really
helpful,


It's complaining that my DMARC record is invalid because it doesn't
start with "v=DKIMv1".  What?

Test ID ttada96061gfwnvbuthbycansr5h34

R's,
John





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] Mail Sending Self-Test Platform

[Tobias Fiebig via mailop]

Heho,
dmarcv1 is a typo in the description (i correctly check for DMARC1,
otherwise this would have shown up earlier); 

The actual complaint is psd=n; Lemme see if i can make the report more
clear re: where it complained.

Do you maybe have some context on psd=n? I can't find it in 7489.

With best regards,
Tobias 

On Tue, 2023-02-28 at 17:32 -0500, John Levine wrote:
> It appears that Tobias Fiebig via mailop  said:
> > Heho,
> > 
> > after our paper on mail sending configurations some time ago [1],
> > we
> > now glued that together into a self-service site: 
> > 
> > https://email-security-scans.org/
> > 
> > I'd be happy to hear your feedback, especially if things do not
> > work as
> > expected (then, your test ID and ideally stored emails would be
> > really
> > helpful, 
> 
> It's complaining that my DMARC record is invalid because it doesn't
> start with "v=DKIMv1".  What?
> 
> Test ID ttada96061gfwnvbuthbycansr5h34
> 
> R's,
> John

-- 
Dr.-Ing. Tobias Fiebig
T +31 616 80 98 99
M tob...@fiebig.nl

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

Re: [mailop] Mail Sending Self-Test Platform

[John Levine via mailop]

It appears that Tobias Fiebig via mailop  said:
>Heho,
>
>after our paper on mail sending configurations some time ago [1], we
>now glued that together into a self-service site: 
>
>https://email-security-scans.org/
>
>I'd be happy to hear your feedback, especially if things do not work as
>expected (then, your test ID and ideally stored emails would be really
>helpful, 

It's complaining that my DMARC record is invalid because it doesn't start with 
"v=DKIMv1".  What?

Test ID ttada96061gfwnvbuthbycansr5h34

R's,
John
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Mail Sending Self-Test Platform

[John Levine via mailop]

It appears that Tobias Geerinckx-Rice via mailop  said:
>Is DNSSEC-signing PTR records common?  Will it affect delivery in 
>practice?

It's not common and I would be astonished if anyone checked as part of delivery.

I have an IPv6 tunnel from Hurricane Electric, who do not do DNSSEC on
their rDNS. My IPv4 addresses are from a local ISP who is hanging on
by her fingernails and I am not going to bother about rDNS changes.
The details of my situation are not all that typical, but the result,
no DNSSEC is quite typical.

R's,
John
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Mail Sending Self-Test Platform

[Tobias Fiebig via mailop]

Heho,
> For DMARC, there is a parsing bug.  My DMARC record consists of three
> concatenated strings, which should be joined as usual.  The view
> shown in the report strips the leading and trailing double quotes,
> but not the intermediate ones:
> 
> v=DMARC1; p=none; " "rua=mailto:dmarca...@tana.it; "
> "ruf=mailto:dmarcf...@tana.it;
> 
> Only v= is parsed correctly; p=, rua= and ruf= result as unset.
Ok, thanks; Identified and fixed.

> For DKIM, the test requires 2048 bit keys.  RFC 8301 says "Signers
> MUST use RSA keys of at least 1024 bits for all keys.  Signers SHOULD
> use RSA keys of at least 2048 bits."  According to RFC 2119, that
> means that there may exist valid reasons in particular circumstances
> to ignore a particular item, but the full implications must be
> understood and carefully weighed before choosing a different course. 
> As I carefully weighted the decision to use a small key —0 attacks in
> several years— I'd have expected an Ok, but watch notes on this.
Hm... I see your point. However, I'd go with 'Should improve', kind of
sticking with the RFC phrasing here; A (more general) issue, though is
the absence of a clear distinction between 'should' level issues, and
'must' level issues (say, missing rDNS alltogether).

What should definately be the case is skipping a warning if there is at
least one other RSA2048 or ED25519 key. Will fix that.


> Also, the diagnostic urges me to sign more header fields. 
> Specifically, it says "see RFC6376 Sec. 5.4: content-transfer-
> encoding:content-type:message-id:mime-version".  It is necessary to
> sign Content-Type: only if the sender signs a limited amount of the
> body, using l=; in that case, altering Content-Type:, a text/plain
> message can be turned into the MIME prologue of a multipart message. 
> Otherwise, signing those fields doesn't add a significant guarantee
> of message integrity.  Signing /technical/ fields, as opposed to
> semantic ones, in my experience irretrievably decrease signature
> resilience.  That is because most mailing lists and other agents
> disregard the original content of such field.  For example, I could
> not verify fiebig.nl's signature of the message I'm replying to,
> whose Content-Transfer-Encoding: was changed to base64, while I
> expect to DKIM verify this message.  See this draft[*] for the method
> to do so.
Hrm, good point. I had initially skipped the approach as in RFC6376;
Following that now, i moved all non-signed headers to 'Ok' (except
for from: being signed.) I will spend more time on thinking about a
good way to address this.

> A test I'd like to make, somewhat more intrusive than replying to
> all, is about DMARC aggregate report correctness.  It would require
> domain owners to provide a target address at their domain.  The
> server would then send a number of messages to that address, some
> from a domain with strict DMARC policies, some from a low-reputation
> IP, some with an EICAR test attached, some from non-existent From:
> domain, and so forth.  On the next day, the diagnostic will examine
> the DMARC report received, if any, and check its correctness, both
> formal and semantic.  Fancy it?

Would be an awesome idea, and i am noting it down. However, given that
there can be a rather strong wind blowing for email measurement setups
that originate emails for measurement purposes (i feel the
implementation we have now is already a stretch with one potentially
unsolicited email being sent), i'll rather skip on that for now.

Thanks for the feedback. Will implement the better handling of multiple
DKIM signatures and then push.

With best regards,
Tobias


-- 
Dr.-Ing. Tobias Fiebig
T +31 616 80 98 99
M tob...@fiebig.nl

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

Re: [mailop] Mail Sending Self-Test Platform

[Tobias Fiebig via mailop]

Heho,
> Thanks for this.  I tried it a few days ago (I think because you 
> posted it to opensmtpd-misc? :-) 
Yeah, also shared it there, hoping for more motivation to implement
DANE/MTA-STS in OpenSMTPd. Next escalation step is releasing code i
wrote for other projects and threatening to send patches. ;-P


> and without doing anything my ‘score’ went from 7 to 8 since I last
> checked!  At this rate I expect a 10 by Friday.
Unlikely ;-) But i got more lenient with DKIM headers, which might have
improved your score.

> Is DNSSEC-signing PTR records common?  Will it affect delivery in 
> practice?
I doubt that it affects deliverability in any way (if, at all,
negatively, if DNSSEC breaks... which... well.) The test mostly works
from a 'perfect world' perspective, and there, of course, everything
DNS would be DNSSEC signed. ;-)

> One confusing UI thing: under ‘DMARC’, the ‘(default)’ is either 
> in error or its meaning unclear:
> 
>   adkim s (default)    (plain-text; OPTIONAL; default is "r".) 
>   …
>   aspf  s (default)    (plain-text; OPTIONAL; default is "r".) 
>   …
>   fo    1 (default)    … (plain-text; OPTIONAL; default is 
>   "0").

Thanks for catching that; Found and fixed. :-) Pushing when i am
through all the feedback.

With best regards,
Tobias
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Mail Sending Self-Test Platform

[Tobias Fiebig via mailop]

Heho,

> Looks like an useful utility for testing these things out live.
Thanks!

> One thing though, the EHLO and rDNS comparison is case-sensitive,
> there should really be no need?

No, there indeed isn't; Thanks, good catch! Already patched and will
deploy in a bit (some more bugs to address from other messages).

With best regards,
Tobias
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Mail Sending Self-Test Platform

[Tobias Geerinckx-Rice via mailop]

Hi Tobias,

Thanks for this.  I tried it a few days ago (I think because you 
posted it to opensmtpd-misc? :-) and without doing anything my 
‘score’ went from 7 to 8 since I last checked!  At this rate I 
expect a 10 by Friday.


Is DNSSEC-signing PTR records common?  Will it affect delivery in 
practice?


One confusing UI thing: under ‘DMARC’, the ‘(default)’ is either 
in error or its meaning unclear:


 adkim s (default)(plain-text; OPTIONAL; default is "r".) 
 …
 aspf  s (default)(plain-text; OPTIONAL; default is "r".) 
 …
 fo1 (default)… (plain-text; OPTIONAL; default is 
 "0").


Kind regards,

T G-R


signature.asc
Description: PGP signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Mail Sending Self-Test Platform

[Taavi Eomäe via mailop]

Hi,

Looks like an useful utility for testing these things out live.

One thing though, the EHLO and rDNS comparison is case-sensitive, there 
should really be no need?



On 27/02/2023 13:59, Tobias Fiebig via mailop wrote:

Heho,

after our paper on mail sending configurations some time ago [1], we
now glued that together into a self-service site:

https://email-security-scans.org/

I'd be happy to hear your feedback, especially if things do not work as
expected (then, your test ID and ideally stored emails would be really
helpful, so i can double check what went wrong). More details below
(also see [2] for an overview of the tests we run).

Please note that setting up the tests (as we have to configure vhosts
for some MTA-STS cases etc.) takes some time on our site. The test-site
should periodically reload and provide the status. As we use JS for
that part, please reload it manually every few minutes if you block JS.

I would also be interested to hear what you think should be included in
addition to the current tests; Some of our plans for the future below
as well.

We already found some interesting bits, like Vultr having lame v6
delegation for their AuthNS servers' domain, making their domain and
rDNS non v6-resolvable [3], or mail-in-a-box using relaxed/simple for
DKIM, which breaks signature validity on long To: headers [4].

If you want me to block certain domains/IPv(4|6) ranges or ASes for the
service to keep your users from using it, please let me know and i will
implement it asap.

# Overview

The site tests a variety of parameters about mail sending (details:
[2]), by evaluating mails a user sends us in reply to a message that
can be requested on the site. Simply requesting a message on the site
does not start any evaluation or measurements, i.e., you have to send a
reply-all to a requested message to start the evaluation. After the
test, you can also delete the test or download a copy of your data, and
if you opted to do so, a copy of the emails as we received them.

# Method

Users send emails to us (in reply-all to a message we sent, for easier
usability).Target MXes on our site are either configured in a fully RFC
compliant way, or intentionally misconfigured in a common way (broken
DNSSEC for the domain, for example, or a broken DANE record, again, see
[2] for an overview). Thereby, we can determine the
configuration/support of features by the senders' MXes.

# Possible Harm

The worst thing that should happen to mail operators is finding
specific undeliverable mails (broken DNSSEC if DNSSEC is validated, v6
only DNS if no IPv6 DNS resolution is supported) in their mail queue,
or users receiving bounces (see FAQ on the page). So far the system has
been tested with several hundred mail-setups, without encountering
issues. If you encounter other unintended side-effects, please reach
out to ab...@email-security-scans.org or me directly off-list.

# Test details

Specifically, we are testing:
- v4 Mail sending
- v6 Mail sending
- Greylisting support

- Transport encryption (Plaintext/TLS cipher strength and version
support, opportunistic encryption)
- DANE support outbound, i.e., if you honor DANE
- MTA-STS support outbound, i.e., if you honor MTA-STS (incl. whether
you prefer DANE over MTA-STS, as it should be)
- Sending of TLS reports and whether these are standard compliant, also
providing a copy of the received report (Google's are not perfect, btw.
;-))

- DNS resolvers used by the mailserver
- Whether the mailers' DNS servers resolve via IPv6
- Whether the mailers' DNS servers validate DNSSEC

- If all names relevant for email delivery resolve via IPv6
- If all names relevant for email delivery are DNSSEC signed

- Mailer-basics (ehlo=rdns=fcrdns), SPF (from/envelope)
- SPF policy size (by retrieving your policy, up to 20 referrals deep)
- DKIM (also checking key-sizes, algorithm mismatches and
canonicalization issues; These are surprisingly common, i.e., simple
being set breaking only in cases not caught by standard dkim testers)
- DMARC (policy validity, conformance of sent mails, displaying
implicit defaults)
- DMARC report deliverability by sending one(1) valid DMARC report for
a received email, including authorization of out-of-domain RUA/RUF
(also providing a copy of any bounces received)

- Full IPv6 readiness (join over three previous IPv6 tests)

- Whether any headers that should not be duplicated are duplicated
- Whether any mandatory headers are missing
- If From/Envelope match

# Planned tests

- evaluate outbound spam filtering
- evaluate received_from stripping
- test for inbound-link parsers
- cluster by provider (via MTA sets), not domain
- Add DANE checks for senders' MXes
- test for host-addresses in SPF prefixes
- add MTA-STS check for senders' domains
- add test for handling more than 5 MX with only the lowest-prio one(s)
being reachable
- requesting-domains' MX aspects (null MX, IPv4/6 addr in MX record,
non-reachable MX, broken MTA-STS/TLSA, broken DNSSEC, 

Re: [mailop] Mail Sending Self-Test Platform

[Alessandro Vesely via mailop]

On Mon 27/Feb/2023 12:59:04 +0100 Tobias Fiebig via mailop wrote:


I'd be happy to hear your feedback, especially if things do not work as 
expected (then, your test ID and ideally stored emails would be really 
helpful, so i can double check what went wrong).



My DMARC and DKIM results were marked as ⛔ should improve, which particularly 
surprises me since I set them up carefully.

My test ID is czs3fbcsxia2wjrgfqtparq1jpl82t.


For DMARC, there is a parsing bug.  My DMARC record consists of three 
concatenated strings, which should be joined as usual.  The view shown in the 
report strips the leading and trailing double quotes, but not the intermediate 
ones:

v=DMARC1; p=none; " "rua=mailto:dmarca...@tana.it; " 
"ruf=mailto:dmarcf...@tana.it;

Only v= is parsed correctly; p=, rua= and ruf= result as unset.


For DKIM, the test requires 2048 bit keys.  RFC 8301 says "Signers MUST use RSA keys 
of at least 1024 bits for all keys.  Signers SHOULD use RSA keys of at least 2048 
bits."  According to RFC 2119, that means that there may exist valid reasons in 
particular circumstances to ignore a particular item, but the full implications must be 
understood and carefully weighed before choosing a different course.  As I carefully 
weighted the decision to use a small key —0 attacks in several years— I'd have expected 
an Ok, but watch notes on this.

Also, the diagnostic urges me to sign more header fields.  Specifically, it says 
"see RFC6376 Sec. 5.4: 
content-transfer-encoding:content-type:message-id:mime-version".  It is necessary to 
sign Content-Type: only if the sender signs a limited amount of the body, using l=; in 
that case, altering Content-Type:, a text/plain message can be turned into the MIME 
prologue of a multipart message.  Otherwise, signing those fields doesn't add a 
significant guarantee of message integrity.  Signing /technical/ fields, as opposed to 
semantic ones, in my experience irretrievably decrease signature resilience.  That is 
because most mailing lists and other agents disregard the original content of such field. 
 For example, I could not verify fiebig.nl's signature of the message I'm replying to, 
whose Content-Transfer-Encoding: was changed to base64, while I expect to DKIM verify 
this message.  See this draft[*] for the method to do so.



I would also be interested to hear what you think should be included in
addition to the current tests; Some of our plans for the future below
as well.



A test I'd like to make, somewhat more intrusive than replying to all, is about 
DMARC aggregate report correctness.  It would require domain owners to provide 
a target address at their domain.  The server would then send a number of 
messages to that address, some from a domain with strict DMARC policies, some 
from a low-reputation IP, some with an EICAR test attached, some from 
non-existent From: domain, and so forth.  On the next day, the diagnostic will 
examine the DMARC report received, if any, and check its correctness, both 
formal and semantic.  Fancy it?


Best
Ale
--

[*] 
https://www.ietf.org/archive/id/draft-vesely-dmarc-mlm-transform-07.html#name-the-reversion-method








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

Re: [mailop] Mail Sending Self-Test Platform

[Tobias Fiebig via mailop]

Heho,
> The inevitable questions about how bad the issues are. I.e. what
> could happen?:
> - My ip4 and ip6 reverse DNS records are not DNSSEC-signed. I could
> ask my hosting provider if they can sign them. Could there be a
> reason not to?
> - I'm not DKIM-signing the MIME-Version header (marked as minor
> issue).
Well, as long as your mail gets delivered, it is not to bad, is it?
;-)

More seriously; The indicators are more like "should improve" (stop-
shield), "could improve" (road-block), and "fun-fact" (light bulb on
'ok').

Nobody will die (or rather: Have their mails not delivered) if your
rDNS is not DNSSEC signed. But in an ideal world it should be.
Naturally, non-fcrDNS is a lot worse than that; But then again, you
should be able to interpret that when running a mail-server. ;-)

For DKIM, btw, i got poked re: my rather RFC4871-ish interpretation; I
revisited that to now only add a note (small light-bulb) if some
headers in the 'think about doing it depending on your use-case'-frame
introduced with RFC6376 are unsigned, while not signing From: now
triggers a "should improve".

> I'm happy to see my ed25519 dkim signatures are accepted by someone.
> (:
Fun story how the setup got to that, actually... during testing a
tester had an RSA key marked as ed25519 in DNS, while signing with an
actual ed25519 key; Lead to a lot more fine-grained evaluation in the
tool, incl. plausibility checks for pubkeys in the DNS.

With best regards,
Tobias

-- 
Dr.-Ing. Tobias Fiebig
T +31 616 80 98 99
M tob...@fiebig.nl

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

Re: [mailop] Mail Sending Self-Test Platform

[Mechiel Lukkien via mailop]

On 2/27/23 12:59, Tobias Fiebig via mailop wrote:

after our paper on mail sending configurations some time ago [1], we
now glued that together into a self-service site:

https://email-security-scans.org/

I'd be happy to hear your feedback, especially if things do not work as
expected


Nice!
Results seem accurate for my case. That is, the issues it found seem correct 
(haven't checked all green checkmarks for accuracy).

The inevitable questions about how bad the issues are. I.e. what could happen?:
- My ip4 and ip6 reverse DNS records are not DNSSEC-signed. I could ask my 
hosting provider if they can sign them. Could there be a reason not to?
- I'm not DKIM-signing the MIME-Version header (marked as minor issue).

I'm happy to see my ed25519 dkim signatures are accepted by someone. (:

Cheers,
Mechiel
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] Mail Sending Self-Test Platform

[Tobias Fiebig via mailop]

Heho,

after our paper on mail sending configurations some time ago [1], we
now glued that together into a self-service site: 

https://email-security-scans.org/

I'd be happy to hear your feedback, especially if things do not work as
expected (then, your test ID and ideally stored emails would be really
helpful, so i can double check what went wrong). More details below
(also see [2] for an overview of the tests we run). 

Please note that setting up the tests (as we have to configure vhosts
for some MTA-STS cases etc.) takes some time on our site. The test-site
should periodically reload and provide the status. As we use JS for
that part, please reload it manually every few minutes if you block JS.

I would also be interested to hear what you think should be included in
addition to the current tests; Some of our plans for the future below
as well.

We already found some interesting bits, like Vultr having lame v6
delegation for their AuthNS servers' domain, making their domain and
rDNS non v6-resolvable [3], or mail-in-a-box using relaxed/simple for
DKIM, which breaks signature validity on long To: headers [4].

If you want me to block certain domains/IPv(4|6) ranges or ASes for the
service to keep your users from using it, please let me know and i will
implement it asap.

# Overview

The site tests a variety of parameters about mail sending (details:
[2]), by evaluating mails a user sends us in reply to a message that
can be requested on the site. Simply requesting a message on the site
does not start any evaluation or measurements, i.e., you have to send a
reply-all to a requested message to start the evaluation. After the
test, you can also delete the test or download a copy of your data, and
if you opted to do so, a copy of the emails as we received them.

# Method

Users send emails to us (in reply-all to a message we sent, for easier
usability).Target MXes on our site are either configured in a fully RFC
compliant way, or intentionally misconfigured in a common way (broken
DNSSEC for the domain, for example, or a broken DANE record, again, see
[2] for an overview). Thereby, we can determine the
configuration/support of features by the senders' MXes.

# Possible Harm

The worst thing that should happen to mail operators is finding
specific undeliverable mails (broken DNSSEC if DNSSEC is validated, v6
only DNS if no IPv6 DNS resolution is supported) in their mail queue,
or users receiving bounces (see FAQ on the page). So far the system has
been tested with several hundred mail-setups, without encountering
issues. If you encounter other unintended side-effects, please reach
out to ab...@email-security-scans.org or me directly off-list.

# Test details

Specifically, we are testing:
- v4 Mail sending
- v6 Mail sending
- Greylisting support

- Transport encryption (Plaintext/TLS cipher strength and version
support, opportunistic encryption)
- DANE support outbound, i.e., if you honor DANE
- MTA-STS support outbound, i.e., if you honor MTA-STS (incl. whether
you prefer DANE over MTA-STS, as it should be)
- Sending of TLS reports and whether these are standard compliant, also
providing a copy of the received report (Google's are not perfect, btw.
;-))

- DNS resolvers used by the mailserver
- Whether the mailers' DNS servers resolve via IPv6
- Whether the mailers' DNS servers validate DNSSEC

- If all names relevant for email delivery resolve via IPv6
- If all names relevant for email delivery are DNSSEC signed

- Mailer-basics (ehlo=rdns=fcrdns), SPF (from/envelope)
- SPF policy size (by retrieving your policy, up to 20 referrals deep)
- DKIM (also checking key-sizes, algorithm mismatches and
canonicalization issues; These are surprisingly common, i.e., simple
being set breaking only in cases not caught by standard dkim testers)
- DMARC (policy validity, conformance of sent mails, displaying
implicit defaults)
- DMARC report deliverability by sending one(1) valid DMARC report for
a received email, including authorization of out-of-domain RUA/RUF
(also providing a copy of any bounces received)

- Full IPv6 readiness (join over three previous IPv6 tests)

- Whether any headers that should not be duplicated are duplicated
- Whether any mandatory headers are missing
- If From/Envelope match

# Planned tests

- evaluate outbound spam filtering
- evaluate received_from stripping
- test for inbound-link parsers
- cluster by provider (via MTA sets), not domain
- Add DANE checks for senders' MXes
- test for host-addresses in SPF prefixes
- add MTA-STS check for senders' domains
- add test for handling more than 5 MX with only the lowest-prio one(s)
being reachable
- requesting-domains' MX aspects (null MX, IPv4/6 addr in MX record,
non-reachable MX, broken MTA-STS/TLSA, broken DNSSEC, validation of our
setups SPF/DKIM (via DNS server logs, v6 resolvability), etc.). 

With best regards,
Tobias


[1] https://www.usenix.org/system/files/atc22-holzbauer.pdf
[2] https://www.email-security-scans.org/description.php