Re: [mailop] (Mis)use of DKIM's length tag and it's impact on DMARC and BIMI

[Taavi Eomäe via mailop]

On 18/05/2024 01:53, Alex Liu wrote:
I dont know this is that new with regard to DMARC. missing citation: 
https://www.usenix.org/system/files/sec20-chen-jianjun.pdf


Thanks for the reference, I'll give it a read when I get the chance. 
Email is quite old by now, so the amount of resources to go through is 
rather immense.



Every a few months we see a paper / blogpost that passes SPF / DKIM / 
DMARC. So maybe requiring both SPF and DKIM for BIMI would be a good idea.


Both together might make sending a bit too error-prone. Hardening DKIM 
seems more doable. I hope that IETF's mailmaint gets to discuss topics 
like these and maybe we'll see some standardized approaches.




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

Re: [mailop] (Mis)use of DKIM's length tag and it's impact on DMARC and BIMI

[Taavi Eomäe via mailop]

On 17/05/2024 18:37, Slavko via mailop wrote:

I didn't get what is **new** in it, nor how length of RSA keys is related...


Turning the original content into a comment seemed novel to us, should 
in theory yield better forgeries than just adding new boundaries. 
Gmail's "show original" also seems to hide such comments for some reason 
(making it extra nasty).




The l= DKIM tag was problematic in time of RFC, the Content-Type
constructs core of message, thus have to be (over)signed already.


As written, it has been known for a while. But given how prevalent it 
really is and how it has opened up new avenues of abuse, we felt it was 
time to call for some action once again.



Best Regards



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

[mailop] (Mis)use of DKIM's length tag and it's impact on DMARC and BIMI

[Taavi Eomäe via mailop]

Hi!

As part of coordinated disclosure, I am sharing it here as well. In 
short, using the approach described below, attackers can replace the 
entire contents of a letter, in a way the letters still pass DKIM’s 
cryptographic checks. This also means these forged letters can be easily 
replayed to reach their victims. This subverts many of the expectations 
operators have about DKIM signatures, DMARC and BIMI.


Although some of these dangers have been known for a while (some parts 
are even described in the RFC itself), things like the threat landscape, 
our approach and the extent to which this can be abused have changed. In 
our opinion previously suggested and (rarely) implemented mitigations do 
not reduce these risks sufficiently.


We hope that with some cooperation from mail operators improved defense 
measures can be implemented to strengthen DKIM for everyone.



A longer description with images is available here: 
https://www.zone.eu/blog/2024/05/17/bimi-and-dmarc-cant-save-you/




Best Regards,
Taavi Eomäe
Zone Media OÜ



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

Re: [mailop] Ubuntu Noble/24.04 - TLS 1.0, 1.1 and DTLS 1.0 are forcefully disabled

[Taavi Eomäe via mailop]

On 14/03/2024 15:15, Matus UHLAR - fantomas via mailop wrote:
Doesn't this mean that if we disable weak ciphers and exchanges, there 
are still some secure options left even with tls 1.0/1.1 ? 


You'd be left with one (two-ish), ECDHE+CBC+SHA1+AES128 or AES256. CBC 
being the "weakest" part in that combination due to how hard it is to 
safely implement, but it's not broken (in theory) on its own (but 
caveats apply). Maybe also a couple with ARIA or CAMELLIA, but that's 
even rarer in terms of trying to be compatible. Shouldn't rely on DHE 
because it's a potential DoS risk or RSA KeX because it can't provide 
PFS. But disabling either has probably the biggest impact on backwards 
compatibility.


In the end there really aren't any that are good, there's only a few 
that are better than plaintext.




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

Re: [mailop] Ubuntu Noble/24.04 - TLS 1.0, 1.1 and DTLS 1.0 are forcefully disabled

[Taavi Eomäe via mailop]

On 13/03/2024 16:43, Bill Cole via mailop wrote:

What is "poor" or "weak" about TLSv1.0 and TLSv1.1 which is relevant
in the context of SMTP, other than their easily-disabled support for
weak ciphers?


If you disable all the weak ciphers and key exchanges you're not left 
with a significant amount of backwards compatibility. Clients that 
support the better subset will most likely also speak newer versions of 
TLS. That's not to say there aren't any exceptions at all, but in general.


The usefulness of older TLS versions is fading quickly, especially 
compared to the risk of dangerous implementation flaws.


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

Re: [mailop] Recommended ciphers used for ESMTP connections

[Taavi Eomäe via mailop]

On 04/03/2024 18:30, Cyril - ImprovMX via mailop wrote:

And we only accept TLS at v1.2 and higher.


Because SMTP is opportunistic you can't be too restrictive. Allowing 
TLSv1.1 would likely provide more compatibility. If you want to enforce 
security, implement MTA-STS.


OpenSSL has built-in presets named "HIGH", "MEDIUM" and "LOW". You can 
just use "HIGH:MEDIUM:!LOW:!DHE" and it will provide a very compatible 
set of ciphers (without allowing DHE that could allow DoS). You should 
also enable server-side ciphersuite preference.


This configuration reduces maintenance burden, if OpenSSL developers 
find something very broken it'll get disabled with an update because you 
haven't forced a bad inclusion.




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

Re: [mailop] Is forwarding to Gmail basically dead?

[Taavi Eomäe via mailop]

On 14/02/2024 20:44, Gellner, Oliver via mailop wrote:

Do you have more information about passkeys in regards to S/MIME certificates? 
This sounds interesting. Or do you only mean that passkeys as well as S/MIME 
both use asymmetric keys?


I just meant that passkeys are a real-life example how the management of 
asymmetric keys can be simplified for end-users. It's likely possible 
that this infrastructure could be leveraged in the future for S/MIME as 
well. I'm not aware that anyone is trying or has done so yet.


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

Re: [mailop] Is forwarding to Gmail basically dead?

[Taavi Eomäe via mailop]

On 13/02/2024 05:16, John Levine via mailop wrote:

Right now if you get a message from Gmail or Yahoo with a valid DKIM signature, 
you
can be quite confident that it came from whichever Gmail or Yahoo user
is in the From header.


That's absolutely not the guarantee provided by DKIM though.


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

Re: [mailop] Is forwarding to Gmail basically dead?

[Taavi Eomäe via mailop]

On 12/02/2024 21:57, Dave Crocker via mailop wrote:
While it has gained respectable amounts of implementation in MUAs, it 
has achieved use only in specialized environments.  Any technology 
with a record that poor should be treated extremely skeptically, when 
considering future use


I've described one of the reasons why that's the case. The other reason 
is probably the fact that key management is incredibly difficult. Which 
is also probably why it has seen adoption in environments that simplify 
it - large organizations or entire countries. Both of these aspects have 
seen advances recently, the CA/B Forum S/MIME baseline and 
implementations for synchronizing cryptographic keys (currently in the 
form of Passkeys).


In the end email is not going anywhere in the next 10-20 years, it would 
be relatively short-sighted to assume that the expectations about 
communications integrity will not increase. If that demand is not 
satisfied somehow then we can only hypothesize about the potential outcomes.



BIMI is a marketing protocol, for promoting brand logos.  What 
anti-abuse benefit do you believe accrues with its use, and how 
exactly do you believe it will achieve that?


It's a bit more than that, but I'm not going to debate that.

A combination of identity validated S/MIME certificate and organization 
validated BIMI provides rather strong guarantees about the signer of a 
letter. It would also probably ameliorate the cost of the validation 
processes and simplify programmatic validation. If you find BIMI 
expensive you should see how much a proper S/MIME deployment costs... 
This is all assuming that an organization aims to get all their ducks in 
a row.




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

Re: [mailop] Is forwarding to Gmail basically dead?

[Taavi Eomäe via mailop]

On 09/02/2024 08:13, Marco Moock via mailop wrote:

S/MIME exists and I really don't understand why banks and online shops
don't consequently use it.


I'd guess it's because until recently, there were way bigger fish to 
fry. Now attention has been turned back towards it, the CA/B Forum 
S/MIME baseline was adopted just recently. Making it possible to 
automate S/MIME certificate renewal (automation which we've come to 
realize is quite vital to avoid downtime).


Not to mention the relative complexity of implementing it on both sides. 
I discovered a major flaw in Apple Mail's S/MIME implementation 
CVE-2023-40440 . S/MIME by 
now is old enough that we've got a layer of cruft to remove before it's 
usable.


My hope is that at some point we would be able to do "BIMI" with just 
S/MIME signed mail at some point. Seems like a good combination.


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

Re: [mailop] Is forwarding to Gmail basically dead?

[Taavi Eomäe via mailop]

On 08/02/2024 20:23, Randolf Richardson, Postmaster via mailop wrote:

Are there any particular DKIM/ARC mangles you've seen that come to
mind for you that are particularly noteable?  =D


The few we've seen were forwarded from Microsoft or GSuite to some 
gateway that broke both signatures (but passed SPF). It's quite rare, 
there have been only a few cases across hundreds of millions, but we 
keep an eye on this stuff.


It's way more common that there's no DKIM in the first place, which is a 
pity.


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

Re: [mailop] Is forwarding to Gmail basically dead?

[Taavi Eomäe via mailop]

On 09/02/2024 04:17, Andre van Eyssen via mailop wrote:
The bulk of problematic email now -- I see phishing as the concern 
rather than spam that gets easily tagged -- comes with valid SPF and 
is signed with DKIM. Technical solutions just don't work these days [...]


That's the joy of authenticated mail though, isn't it? Instead of having 
to deal with both the non-technical and technical you can deal with just 
the former and ban specific signers for example.




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

Re: [mailop] Is forwarding to Gmail basically dead?

[Taavi Eomäe via mailop]

On 08/02/2024 04:51, Jarland Donnell via mailop wrote:

Is it time to throw in the towel on email forwarding?


We're successfully forwarding tens of thousands of emails to Gmail, 
Yahoo and others.


We try not to break DKIM and we also use ARC, that seems to satisfy most 
for now. We've even seen letters with intact ARC chains that have gone 
from Google to Microsoft to us and then back to Google.


Most of the annoyance seems to be caused by senders that mangle their 
DKIM (and ARC) before the letter makes it to us in the first place.




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

Re: [mailop] problem setting up open-dmarc

[Taavi Eomäe via mailop]

Anything that created a multi-million dollar industry of consultants 
on how to set up DMARC, well.. email should NOT be that difficult.. 


If you use even a relatively modern email stack then it's quite trivial 
through rspamd for example. Some have it (and more) even built-in, like 
Stalwart or Maddy.



Unless you are a big budget email sender, don't stress to much.  Maybe 
tomorrow we will need something like DMARC, but thankfully not yet today. 
You need it right now if you want to protect your communication against 
forgeries.





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

Re: [mailop] BIMI boycott?

[Taavi Eomäe via mailop]

On 10/01/2024 19:18, Jaroslaw Rafa via mailop wrote:

As the OP has written, the only ones that may be interested in this may be
marketers. Nobody else needs any logos, avatars etc. displayed alongside the
email headers.


That is certainly an overly bold claim. For a lot of people it makes 
navigating the inbox easier and nicer to look at, it also does make 
phishing a bit harder. We've yet to see how much harder because the 
deployment percentage of good DMARC, not to mention BIMI+VMC, is quite low.



Also, I see no feasible way - neither now nor in the future - to use it any
meaningful way in person-to-person communication, which is the topic OP
asked about, and you seem to have ignored it completely in your answer


It's not really designed for that. It could happen in the form of adding 
the logotype OID to S/MIME certificates, but S/MIME is not that far 
along - the new S/MIME baseline (by the CA/B Forum S/MIME workgroup) is 
really new, and that's just the baseline. Maybe in the future.



Is the goal to make email a closed ecosystem in which only the big players can 
participate?


For context, we at Zone Media have implemented BIMI in our mail server 
and web email client, we have also published a BIMI record with VMC. I'd 
say it's far from being something only "big players" can participate in, 
unless you consider us a big player...


Verifying identity is a difficult problem, maybe it doesn't work out in 
this exact form or way, but it's empirically evident that the problems 
BIMI tries to address are real. Boycotting it for the cost is as silly 
as boycotting entire S/MIME for the same reason.


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

Re: [mailop] ECDSA DKIM validation?

[Taavi Eomäe via mailop]

Considering how Gmail and quite a few widespread DKIM implementations 
still don't support EdDSA DKIM, I wouldn't get my hopes too high.




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

Re: [mailop] DKIM / slippery slope gmx.de

[Taavi Eomäe via mailop]

> And it seems none of the extra requirements do anything against
spam, because the spammers can (and do, see above) easily implement
all of those.

I get the impression you can't see the forest for the trees. These 
methods being easy to implement is exactly the goal. Once majority of 
mail is properly authenticated more effective methods can be used to 
fight spam as content-based filtering is increasingly difficult, 
sender-based will get somewhat more attention.


These two errors from an another thread on this list are a great example:

> 421-4.7.28 Gmail has detected an unusual rate of unsolicited mail 
originating from your SPF domain [userdomain.tld 15]. To protect our 
users from spam, mail sent from your domain has been temporarily rate 
limited. For more information, go to 
https://support.google.com/mail/?p=UnsolicitedRateLimitError to review 
our Bulk Email Senders Guidelines. 
o13-20020a056870200d00b002033c710f0asi2122725oab.109 - gsmtp


> 421-4.7.28 Gmail has detected an unusual rate of unsolicited mail 
originating from your DKIM domain [ 15]. To protect our users from spam, 
mail sent from your domain has been temporarily rate limited. Please 
visit https://support.google.com/mail/?p=UnsolicitedRateLimitError to 
review our Bulk Email Senders Guidelines. 
y5-20020a056808130500b003b3eaa2eb4esi890433oiv.53 - gsmtp


Anyways, it's about time hosts start punishing lack of DKIM (more).


Best regards,
Taavi Eomäe



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

Re: [mailop] Success MiTM attack

[Taavi Eomäe via mailop]

On 22/10/2023 16:08, Slavko via mailop wrote:

Hmm, and what about MUAs?


Without MUA-STS, it's up to the MUAs and only MUAs to enforce connection 
security. The next step after that would be some kind of pinning.


Some have suggested DANE+DNSSEC, but DNSSEC operators can be coerced 
just as much as hosting providers can be, but unlike with WebPKI, it 
wouldn't even leave a publicly visible trace amongst other problems. 
TOFU schemes in that sense have worked better in real life scenarios 
(but obviously come with other downsides).






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

Re: [mailop] Increase of SSL/TLS errors

[Taavi Eomäe via mailop]

On 12/09/2023 15:33, Bill Cole via mailop wrote:
Your CA (LetsEncrypt) says that is breakage and they offer a fix. Take 
it or leave it, but saying that it isn't broken is wrong. 


It is not wrong.

There's a valid and trusted path, that is sufficient. If your TLS client 
does not build certification paths properly then that's a flaw in the 
software. There is a lot of discussion on this subject so there's no 
point in continuing that here.




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

Re: [mailop] Increase of SSL/TLS errors

[Taavi Eomäe via mailop]

> Can you check on your side that communication is OK with my servers? 
Do I understand correctly that the servers of senders are guilty, and 
it's not something on my side?


Looks correct to me and Hardenize. If anything, TLSv1.0 should probably 
be disabled at this point.


https://www.hardenize.com/report/clean-mailbox.com/1694499180#email_tls



OpenPGP_0x348B4BDC6047AF45.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Increase of SSL/TLS errors

[Taavi Eomäe via mailop]

> TL;DR: you need to fix the chain of trust for your certificate. You 
should remove any reference to the 'DST Root CA X3' certificate. You may 
also need to change how you maintain your certificate.


No. The chain may contain an expired root certificate. A client must 
only validate the chain until the first trusted root. LetsEncrypt's 
should be trusted first, certificate chain must be validated until that 
and accepted.




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

Re: [mailop] hotmail.com SPF forgot IPv6

[Taavi Eomäe via mailop]

On 21/08/2023 17:49, Jarland Donnell via mailop wrote:


I haven't spent much time on ARC but if I understand correctly, isn't 
that a 100% trust based system? Meaning I have to trust that when you 
say you authenticated it, that you're trustworthy when saying it?


Not always but in quite a few cases, yes. If there's no 
cryptographically verifiable trust from the origin there isn't a method 
that can make it appear back. SRS and things like SRS just hide it 
(something akin to "trust that we haven't lied about what address we 
rewrote").


That being said, it's way easier for a forwarder not to break DKIM with 
ARC in the mix. It's also easier for the receiver to trust a forwarder's 
ARC seal than it is to trust their SRS (and methods like it). It is a 
bit of a free pass to do a few things naughty, but in those cases the 
original letters were poorly made (unsigned) anyways (and you can also 
treat them accordingly if the letter hasn't been mangled).


You might see benefit from ARC even forwarding email within a single 
organization. Not to mention through multiple forwarders.




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

Re: [mailop] hotmail.com SPF forgot IPv6

[Taavi Eomäe via mailop]

On 21/08/2023 12:08, Laurent S. via mailop wrote:

  I guess they don't care about breaking DKIM either. Avoiding to break SPF 
isn't rocket science.


Many methods to avoid breaking SPF will break DKIM (if it exists, thus 
DMARC). It's not rocket science, but it's not trivial.


ARC is where it's at, not (only) SPF and SRS-like methods.



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

Re: [mailop] hotmail.com SPF forgot IPv6

[Taavi Eomäe via mailop]

On 19/08/2023 13:16, Benny Pedersen via mailop wrote:
if it was hardfails, lets not ignore domain owners, ever 


An SPF hardfail isn't sufficient for a reject or mark as spam either though.

As previously mentioned, DKIM can be and should be sufficient. But 
there's also the use-case where a trusted ARC forwarder is forced to 
cause a SPF fail, but the recipient can still accept it. Without the 
original letter having a DKIM signature.




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

[mailop] Antivirus/anti-phish email scanning

[Taavi Eomäe via mailop]

Hi,

Does anyone here have any familiarity with antivirus/anti-phish vendors 
that can or are meant to be used with email?


I've checked the rspamd external services page 
(https://rspamd.com/doc/modules/external_services.html#icap-protocol-specific-details) 
and it has a nice list, but no other details.


Has anyone here tested some of those out? What's the reaction speed 
against new malware campaigns? Does it also work against (some) phish? 
Most importantly, are there any that are *not* priced per-mailbox? Any 
warnings or comments would be very appreciated.




Best regards,
Taavi


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

Re: [mailop] Guide for setting up a mail server ?

[Taavi Eomäe via mailop]

On 12/07/2023 15:53, Bill Cole via mailop wrote:
For most sending domains, targeted forgery to the world at large is a 
non-problem. No one is out there impersonating you or me in email to 
random strangers for financial gain.


That is simply not true. For the past two years we have been seeing an 
ongoing onslaught of malicious actors "forging" four-letter .com 
domains. There have been actual cases of the owners of those domains 
wondering why they're ending up in spam. The answer is simple - sorry, 
your letters are not differentiable enough from spam. That's just one 
example of many.


You're never too small to become random collateral. I'd say you're never 
so small to be impersonated either, but I can't share examples of that.


Mechanisms for general public authentication of email from strangers 
exist for the primary benefit of big senders, their customers, and 
their prospective customers who need to know that their spam is 
authentic. 


So yeah, that is absolutely false.



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

Re: [mailop] Guide for setting up a mail server ?

[Taavi Eomäe via mailop]

On 12/07/2023 00:20, Jaroslaw Rafa via mailop wrote:

For start, I suggest to implement SPF, DKIM and DMARC only for outgoing
mail, and in fact only to satisfy Google's requirement that these should be
in place. Don't bother checking them on incoming mail. (It's actually how I
do it).
RBLs and content filtering are enough to protect from spam. I see close to
zero improvement if I would check SPF and/or DMARC. Of course YMMV.


This is a terrible thing to suggest to someone. There's very little 
merit to accepting letters just like that.


More likely you'd be accepting phish, malware and other junk that 
would've gotten rejected if you respected DMARC as requested by 
respective owners of those domains.




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

Re: [mailop] key exchange parameters: ECDHE, DHE, RFC 7919

[Taavi Eomäe via mailop]

On 11/07/2023 20:43, Bastian Blank via mailop wrote:

Given that this host only reacts on port 25 but not on port 587, I
assume this is MX.


Ideally one would offer implicit TLS on port 465 as well (RFC8314).


You are talking about MX, which is unauthenticated in the absence of DANE.


There's also MTA-STS, which doesn't rely on DNSSEC and introduce 
operational complexity.




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

Re: [mailop] Guide for setting up a mail server ?

[Taavi Eomäe via mailop]

Instead of struggling with Postfix, OpenDKIM, Dovecot and friends (and 
losing out on quite a few features). I'd really recommend looking at 
Maddy instead.


Immensely better "UX" than the currently mentioned approach.



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

Re: [mailop] Google Toolbox broken?

[Taavi Eomäe via mailop]

> Based on the all the replies it looks like this tool has several bugs 
and its output can be ignored.


I'd say it's a good reality check of sorts, standards saying "MAY" but 
some implementations saying "MUST". Understandably better 
implementations are... better, but it's not too far-fetched that there 
might be others in the wild with the same or similar complaints, 
impacting deliverability. (I have seen this from both sides when we 
added MTA-STS support to ZoneMTA .)


For the record, I didn't have to make any changes to avoid the two 
errors you spoke about.


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

Re: [mailop] Google Toolbox broken?

[Taavi Eomäe via mailop]

> this is only needed if defaults is not ok, so it follows what is with 
dmarc where all is optional


According to the standard, yes, judging by at least this one tool 
complaining, ehh...


I think applying the robustness principle of being conservative in what 
you do and being liberal in what you accept from others, would be the 
safe and reliable approach here.




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

Re: [mailop] Google Toolbox broken?

[Taavi Eomäe via mailop]

Your DKIM TXT record seems valid, but does not specify the key type, 
looking at the length it should probably contain "k=rsa". Or they might 
not like you specifying acceptable hash algorithms.


Your mta-sts.txt does not have a trailing newline, I'm not sure if the 
standard mandates it, but that seems to be at least one of the differences.


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

Re: [mailop] Microsoft Office365 not rejecting emails when instructed so by SPF recored?

[Taavi Eomäe via mailop]

> It looks like GV0CHE01FT013.mail.protection.outlook.com is happily 
accepting phishing emails which, according to SPF should get rejected.


No, they shouldn't.

Specifying how unauthenticated mail from a domain should be treated is 
done using DMARC.




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

Re: [mailop] Forwarding mail originating from gmail via 3rd party to gmail

[Taavi Eomäe via mailop]

Do those forwarded letters without SRS have intact DKIM?

A second thing you can try is ARC (without the SRS), I've gotten the 
impression that Gmail "likes" original letters (and ARC) more than it 
likes any kind of mangling, including SRS.




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

Re: [mailop] Massive botnet going off today?

[Taavi Eomäe via mailop]

Here's a complete list of the IPs we've seen exhibit behavior specific 
to this botnet. If anyone's interested.
1.10.214.65
1.11.62.185
1.180.217.139
1.180.228.194
1.180.230.98
1.183.3.58
1.192.219.104
1.192.48.32
1.192.48.55
1.193.163.2
1.202.161.50
1.208.117.94
1.212.65.51
1.213.251.50
1.215.116.254
1.215.233.74
1.22.228.147
1.223.107.138
1.226.228.82
1.235.197.58
1.28.193.174
1.28.86.66
1.28.87.38
1.30.20.110
1.30.20.98
1.30.219.108
1.31.83.238
1.53.252.215
1.56.207.92
1.62.154.219
1.63.18.94
1.7.143.66
1.71.249.210
1.71.253.133
1.82.135.154
101.100.184.80
101.13.0.102
101.13.0.103
101.13.0.105
101.13.0.106
101.13.0.107
101.13.0.108
101.13.0.109
101.13.0.11
101.13.0.12
101.13.0.13
101.13.0.14
101.13.0.15
101.13.0.173
101.13.0.18
101.13.0.186
101.13.0.188
101.13.0.19
101.13.0.208
101.13.0.209
101.13.0.210
101.13.0.212
101.13.0.216
101.13.0.22
101.13.0.228
101.13.0.23
101.13.0.230
101.13.0.231
101.13.0.232
101.13.0.238
101.13.0.24
101.13.0.240
101.13.0.246
101.13.0.26
101.13.0.28
101.13.0.30
101.13.0.33
101.13.0.39
101.13.0.4
101.13.0.41
101.13.0.43
101.13.0.49
101.13.0.50
101.13.0.52
101.13.0.56
101.13.0.58
101.13.0.59
101.13.0.6
101.13.0.61
101.13.0.62
101.13.0.7
101.13.0.71
101.13.0.72
101.13.0.74
101.13.0.77
101.13.0.8
101.13.0.81
101.13.0.82
101.13.0.88
101.13.0.9
101.13.0.97
101.13.0.99
101.205.25.59
101.207.143.124
101.207.6.21
101.227.238.65
101.229.214.65
101.230.83.226
101.231.108.174
101.251.197.46
101.34.35.141
101.42.165.213
101.43.107.9
101.43.170.223
101.43.78.92
101.69.248.133
101.78.12.109
101.83.34.218
101.85.38.205
101.95.97.158
102.128.193.2
102.141.21.226
102.164.36.90
102.32.129.118
102.32.130.59
102.90.34.90
103.10.54.189
103.100.9.29
103.103.53.44
103.104.135.210
103.104.29.152
103.104.29.43
103.105.225.43
103.105.226.174
103.106.154.139
103.106.154.15
103.107.36.18
103.107.99.31
103.108.146.96
103.108.156.66
103.108.6.104
103.112.240.12
103.112.252.254
103.112.26.106
103.112.4.246
103.113.83.168
103.114.166.186
103.115.117.176
103.115.117.177
103.118.116.239
103.118.168.67
103.12.246.110
103.121.165.10
103.121.19.171
103.123.234.35
103.129.212.246
103.131.8.193
103.133.120.234
103.135.139.114
103.135.139.115
103.14.38.98
103.141.74.109
103.146.0.135
103.146.233.184
103.146.233.191
103.146.233.213
103.147.140.116
103.147.140.180
103.147.140.188
103.147.140.195
103.147.140.219
103.147.140.228
103.147.140.59
103.147.141.115
103.147.142.172
103.147.142.27
103.147.142.4
103.147.142.51
103.147.143.171
103.147.143.227
103.147.248.12
103.147.248.44
103.147.248.61
103.147.62.157
103.147.64.187
103.147.64.51
103.147.64.52
103.147.66.253
103.152.41.26
103.153.140.39
103.154.238.169
103.155.137.82
103.157.104.248
103.157.123.108
103.157.52.2
103.159.21.114
103.159.21.130
103.159.21.140
103.159.21.147
103.159.21.148
103.159.21.154
103.159.21.18
103.159.21.34
103.159.21.42
103.159.21.52
103.159.21.84
103.159.21.90
103.161.254.150
103.164.26.38
103.167.40.64
103.167.40.67
103.167.40.74
103.167.40.79
103.169.43.241
103.171.101.6
103.171.39.4
103.171.39.6
103.172.94.224
103.174.164.188
103.175.172.114
103.176.163.68
103.178.159.211
103.179.114.42
103.179.165.186
103.181.158.66
103.181.158.67
103.187.110.186
103.187.198.34
103.187.83.129
103.187.83.5
103.192.213.124
103.194.243.183
103.194.88.187
103.199.208.122
103.203.210.30
103.204.119.133
103.204.72.197
103.205.112.25
103.205.15.211
103.206.188.77
103.207.8.96
103.21.186.82
103.212.141.20
103.216.164.26
103.218.100.3
103.220.213.215
103.224.119.102
103.224.166.10
103.224.215.102
103.227.68.33
103.232.247.197
103.233.94.20
103.237.54.140
103.240.103.141
103.245.251.48
103.248.122.253
103.248.32.54
103.249.77.2
103.251.143.14
103.253.175.12
103.26.51.76
103.29.117.46
103.36.124.165
103.37.80.51
103.4.144.86
103.4.64.124
103.44.53.49
103.48.180.248
103.51.139.69
103.53.60.19
103.54.93.58
103.59.196.14
103.63.215.82
103.65.196.2
103.65.197.142
103.65.228.4
103.66.48.67
103.67.227.2
103.68.52.210
103.69.9.237
103.69.9.69
103.70.142.229
103.71.16.98
103.72.178.142
103.73.196.142
103.74.68.131
103.74.71.12
103.75.20.178
103.83.58.242
103.86.146.140
103.86.196.21
103.89.41.236
103.90.177.102
103.92.37.130
103.92.37.147
103.92.37.148
103.92.38.116
103.92.39.188
103.92.39.219
103.92.39.220
103.92.39.243
103.92.47.112
103.93.104.251
103.93.113.228
103.93.184.12
103.93.184.20
103.93.201.58
103.93.37.178
103.93.38.59
103.97.164.147
104.158.110.144
104.174.13.215
104.175.39.58
104.199.219.158
104.231.17.27
104.236.204.222
104.33.199.93
104.37.76.19
104.6.69.88
105.208.23.35
105.233.96.86
105.242.133.7
105.255.121.14
106.1.152.91
106.107.173.49
106.107.229.215
106.112.194.160
106.117.11.172
106.117.205.154
106.117.7.146
106.117.9.5
106.12.109.212
106.12.174.50
106.12.35.52
106.12.48.161
106.120.246.2
106.13.210.51
106.201.230.253
106.201.231.52
106.201.232.177
106.201.233.139
106.201.235.199
106.201.236.236
106.201.238.85
106.201.239.91
106.225.142.244
106.240.41.60
106.242.31.98
106.248.238.187
106.255.231.10
106.255.253.178
106.38.80.226
106.38.94.98

Re: [mailop] Massive botnet going off today?

[Taavi Eomäe via mailop]

Can confirm seeing a similar botnet at action, ~5000 different 
IP-addresses, ~400 million attempts and counting.


Seems to be trying relatively random and unrelated local part + domain 
combinations. This also means this botnet is rather trivial to detect.





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

Re: [mailop] DKIM with 3072-bit or 4096-bit RSA signatures

[Taavi Eomäe via mailop]

On 26/04/2023 14:48, Jaroslaw Rafa via mailop wrote:

If you want to make an e-mail message non-repudiable, you should use end-to
-end content signing using either S/MIME or PGP/MIME. Then the content is
signed either with a certificate issued by publicly recognized CA (in case
of S/MIME), or with PGP key of your correspondent, which you should have in
your "web of trust" (in case of PGP/MIME).


Unfortunately neither S/MIME or PGP have any methods for 
non-reputability after validity time, very fundamentally the same as 
DKIM. The only difference being the signer.


As there's no OCSP-stapling equivalent for S/MIME not to mention for 
PGP, you can't know if the (sub)key or certificate was valid during the 
time of signing.


The correct way would be to use something like an ASiC-E container (with 
a fully qualifying electronic signature under eIDAS). There might be 
alternatives but I'm not aware of any that provide the same security 
(and legal) guarantees.




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

Re: [mailop] SPF behavior on email forwarding

[Taavi Eomäe via mailop]

On 14/04/2023 16:10, Jarland Donnell via mailop wrote:
Correct me if I'm wrong but isn't the trust level of ARC basically 
"trust me bro?" At least SRS and SPF require ownership of the domain.


Even with SRS you're still fundamentally saying "trust me bro" that what 
you rewrote was actually what it was. SPF kinda does require ownership 
but that's the thing you're breaking with the forward... What tips the 
balance even more towards ARC is that you're also not messing up DKIM in 
the process, which means you can say "trust me bro or look at this 
signature."




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

Re: [mailop] SPF behavior on email forwarding

[Taavi Eomäe via mailop]

On 14/04/2023 15:22, Laura Atkins via mailop wrote:
Unless they’re rewriting the envelope, yes. This is part and parcel of 
how SPF works. I’m somewhat surprised that those services are not 
rewriting the envelope, though. Unfortunately, I don’t have the Google 
access / infrastructure to test this and see what they’re doing.


Google supports ARC, SRS is a hack of the past compared to it.



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

Re: [mailop] SPF behavior on email forwarding

[Taavi Eomäe via mailop]

>For me, the reason was pretty straight forward ; you set your SPF in a 
way that you ask for it to fail, so it makes sense that we refuse it if 
... it fails.


Well, no. One should never reject on a simple SPF fail, we have DMARC 
for that. One should only reject (in the context of SPF/DKIM/DMARC) on 
final DMARC failure with a policy p=reject. That is what the standards 
are there for. The new addition ARC will also help you in the case of 
forwards, you can accept letters that passed DMARC initially before the 
forward.


If it's spam you're worried about, filter it out using other means.

Many vendors do reject letters when there's neither SPF or DKIM, however.

> What would be the best behavior here? Should we allow all emails, 
even those who fail SPF? Should we only block when DMARC is set and fails?


The best behavior is to verify SPF, DKIM, DMARC and ARC, all four. Then 
make a standard-based decision based on those, if DMARC still doesn't 
pass then one rejects.


SPF fail shouldn't be the thing that decides the fate of a letter, it's 
not used like that or should be used for that.




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

[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

[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

[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] Compromised email account trends

[Taavi Eomäe via mailop]

Please educate us: how can a standard-compliant MUA use OAuth2 without 
the developer registering the MUA with each service provider they want 
to support?


By implementing RFC7591, OAuth 2.0 Dynamic Client Registration Protocol, 
which allows MUAs to do this automatically.


But as mentioned in the second subthread, not what I meant entirely.



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

Re: [mailop] Compromised email account trends

[Taavi Eomäe via mailop]

> Really? RFC6749:

Maybe I was a bit too eager with the quote earlier as I was really 
pointing at the "register as a developer part."


Your qualm was that *you* have to register as a developer. How that 
process looks like, how tedious it is and how many MUAs already have 
added support is specific to a vendor and its implementation. It in and 
on itself is not a sufficiently large hurdle compared to the positives.


The reason "why" is probably also described in the same standard. For 
example allows you to let the user know which MUA logged in to their 
account. Maybe they don't use Thunderbird at all - instantly suspicious 
and they can revoke that session without messing up all the rest. A 
random IMAP connection with the usual authentication methods probably 
doesn't provide that info. There's certainly more to it, but that's just 
*one* aspect it makes better than before.




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

Re: [mailop] Compromised email account trends

[Taavi Eomäe via mailop]

Why should I need to use a program registered to the service provider
in order to read my email? (Or in my case, register myself as a
developer with Microsoft in order to allow me and my colleagues to
read our own mail.)



You are confusing one vendor's implementation with the standard.



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

Re: [mailop] Compromised email account trends

[Taavi Eomäe via mailop]

This discussion is getting awfully close to reinventing OAuth2.

It's quite clear by now that long-lived tokens that are nearly 
impossible to properly revoke just don't work well in any human-operated 
contexts.


Hopefully we'll see an increase in the adoption of OAuth2 instead of 
rather crude ways of mitigating only half of the issue. Large players 
started pushing Oauth2 for both SMTP and IMAP for a really good reason 
after all.




On 22/02/2023 13:32, Jaroslaw Rafa via mailop wrote:

Dnia 22.02.2023 o godz. 01:51:41 Sebastian Nielsen via mailop pisze:

If you run a hosting service available internationally, do
this:Use a IP to Country service, to get their country.Append country to
password at both creation, change and login time.For example, if my
password is Password123, the password hash in database would be
hash(Password123-Sweden)When trying to login, if I login from sweden, it
would work wonderfully.But if I try to login from Germany, the password
hash would become hash(Password123-Germany) which doesn't match
hash(Password123-Sweden).This is a great way to IP restrict a account so
it only works from the country it was created/bought from.

With this approach, you must *very explicitly* warn your users that their
accounts will work only within the same country. Otherwise, users who are
travelling to another country and expect to be able to access their e-mail
accounts there, might be *very* disappointed. And if someone eg. loses a
big contract due to not being able to access e-mail, you might probably get
sued.

I have also one more idea. Remember the old "POP-before-SMTP" approach from
the times there was no SMTP AUTH yet? I have observed that the
password-cracking bots are heavily attacking submission services, while
relatively very rarely trying to login to IMAP service. On the other hand,
any regular email client first does IMAP login to get the mailbox index, and
then after the user tries to send a message, authenticates to submission
service. So one might simply reject *any* password on submission service, if
there is no recent successful IMAP login to the same account from the same
IP address.


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

Re: [mailop] T-Online is now really blocking messages from non-commercial and simliar senders

[Taavi Eomäe via mailop]

On 21/10/2022 15:36, Bjoern Franke via mailop wrote:

And then tld.t-online.de sends e.g contact form spam from 
"anonym...@hostmaster.telekom.de" and produces backscatter. They don't 
even apply their own rules to their customers. Why should we accept 
mail from tld.t-online.de when we don't know who's reponsible for it? 


I think it has been mentioned multiple times in this massive thread, 
that you don't have to. Just like they don't.


However I wouldn't recommend taking the same allowlist-based approach. 
If you really-really want some attribution, just start requiring the 
existence of an SPF record.





Wishing you a good day,
Taavi



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

Re: [mailop] T-Online is now really blocking messages from non-commercial and simliar senders

[Taavi Eomäe via mailop]

I have my doubts about t-online.de caring about SPF+DKIM+DMARC, not 
having deployed it themselves. It has been quite tedious to filter spam 
abusing that domain.



On 19/10/2022 15:25, Stefano Bagnara via mailop wrote:

On Wed, 19 Oct 2022 at 13:32, Heiko Schlittermann via mailop
 wrote:

A given mailhost (ran privately for smaller entities) can't send
messages to T-Online anymore.

   554 IP=168.119.159.241 - A problem occurred. …

Do you get this error at the connection or after you transmitted the message?

If you get the error after the "DATA" and "." then maybe you just need
DKIM+DMARC compliance for your emails.

In this case look for an old thread here:
"DKIM+DMARC at t-online.de (Deutsche Telekom's ISP branche)" by
florian.kun...@telekom.de (Apr 6 2021)



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

Re: [mailop] Research project on SPF validation: Is your server violating RFC standards for SPF resolution?

[Taavi Eomäe via mailop]

But someone should help these people, and the only way to draw 
attention to the fact they are doing it wrong, is to do things like 
flagging messages from them as 'spammy' or rejections..


If you can 'reject' with a clear message that their SPF record does 
not conform to RFC, then they might understand why the rest of their 
email sometimes has problems..


IMHO..

We can't just keep ignoring Best Practices and RFC's, or what is the use?


In theory that makes perfect sense. If you reject all letters without SPF.

If you don't, you're simply punishing those that are doing better (if 
you raise what is an arbitrary number). You are free to draw parallels 
here with the recent TLS discussion.


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

Re: [mailop] Research project on SPF validation: Is your server violating RFC standards for SPF resolution?

[Taavi Eomäe via mailop]

Specifically, we would like to know more about your setups of your MXes are not 
following the limits of RFC7208, specifically if this comes from software 
defaults or might even have been a conscious choice. We are also preparing a 
survey on SPF behavior, which we will share shortly.



The rspamd¹ default is 30. I'd say it works better that way in practice, 
because people do make mistakes and vendors do modify the records 
customers /include/.



[1]: https://rspamd.com/doc/modules/spf.html#example-configuration
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Gmail Dynamic Email / Impact on Email Ecosystem

[Taavi Eomäe via mailop]

They seem to be a text/x-amp-html, and require a text/html or
text/plain fallback, so other clients would simply use the fallback.


I think many of us have seen the "fallback" from text/html to 
text/plain. "Sorry your e-mail client can't display HTML", well it can 
but I kinda prefer text first and you just sent me useless garbage.



The following is not directly related to your letter, just the topic.

I do understand the need for something better than the inconsistent (and 
thus difficult) text/html we have now. Static-only AMP might even fit 
the bill, but static letters do not seem to be the goal at the moment.


Unfortunately I don't see anyone but the giants succeeding in pushing 
for a new widely-supported content type either. Just looking at the 
deployment of other email improvements. I've long yearned for something 
like text/restructured or text/markdown that is trivial to convert to 
both text and HTML, but looks nicer if natively rendered and is easy to 
manually type out.


Anyways, point being that if we don't want AMP there should be an 
equally attractive alternative widely deployed.


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

Re: [mailop] [E] Re: Gmail Dynamic Email / Impact on Email Ecosystem

[Taavi Eomäe via mailop]

Yeah, just like any website can "change". I encourage you to dive a 
little deeper into the capabilities (and non-capabilities) for that 
matter ;-)


Sure, and those of us who have had to deal with taking down phishing 
that is very selective know the pain. That pain shouldn't exist in 
emails themselves. Taking Gmail's other feature as well, confidential 
emails. YIKES


Imagine this scenario:
"I got this letter, it looks very suspicious"
"Can you forward it to me?"
"I can't it won't let me, says something about being marked confidential"
"Okay just show it to me then"
"I opened it again and it has changed"


No.  Not the MTA anyway.


It depends where you're doing your filtering.

Yes, and horses are sufficiently fast and 64kb ought to be enough for 
everybody ;-)


Just send links if you need to display dynamic content, that's what 
links are for. Alternatively implement a diff scheme that would allow 
building the end result. Messages already delivered shouldn't change 
without either clear indication or user preference that they may.


Even though I loathe "you just got a reply to your comment"-emails, 
they're better than ones I might open years from now, potentially broken.


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

Re: [mailop] Disabling TLS 1.0 and 1.1 for MTA to MTA communication

[Taavi Eomäe via mailop]

Gmail has a "security" line in the drop down which shows more 
information about the sender, recipients, etc.  I have many messages 
in a mailbox that state:


   security:  Standard encryption (TLS) Learn more

With a padlock icon in front of Standard and Learn more being a link.

So there is some amount of information being surfaced to user -- if 
they know where to look -- indicating that the message is secure.


You're correct. My perspective on the UI might be different because of 
how S/MIME encrypted (or signed) letters look like in Gmail. I didn't 
consider a gray padlock an indication of "being secure" when it could've 
been... well, green. But I guess some users might.


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

Re: [mailop] Disabling TLS 1.0 and 1.1 for MTA to MTA communication

[Taavi Eomäe via mailop]

The (very important) thing is that NO email can be considered "secure" 
unless it is end-to-end encrypted (eg PGP), without any third party 
service knowing the encryption key, or you personally know and trust 
all the mail administrators of all the mail servers involved.


Exactly the point I tried to make. Nobody (and rightfully so) displays 
transport encryption as secure, which invalidates the original premise 
of someone being lied to in the first place.


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

Re: [mailop] Disabling TLS 1.0 and 1.1 for MTA to MTA communication

[Taavi Eomäe via mailop]

Why are there any efforts to remove old TLS versions from every major 
software application and operating system? Are all of these security 
experts and corporations just playing a game with TLS versions, or is 
there perhaps something to this security practice?


Because browsers won't fall back to plaintext, there are even methods to 
further prevent that (HSTS). Not to mention that web servers will 
upgrade their offering in order to stay accessible. They have the agility.


If you've got validated certificates and MTA-STS in the play and some 
megacorporations flipping that switch on MTAs then we could do the same, 
but that isn't the case. We don't even have MUA-STS, the two ecosystems 
are just so far apart at this point in terms of cryptography that these 
comparisons are borderline bad.


Both being insecure, only one of the two involves your server 
negotiating and reporting to the third party that you are accepting it 
over a secure connection. Which is basically a lie. Plain isn't a lie, 
and that's worth something. 


You can't consider it a lie if nobody is asking the question in the 
first place. Gmail /might/ show when an email was delivered in plaintext 
as *insecure* it does not display transport-encrypted emails as 
*secure*. What displays transport encryption as  "secure"?


Where as if you say "This is a secure line" and it isn't because the 
other party either doesn't know what they're doing or is the victim of 
a downgrade attack (through whatever attack vector that came from) 
then the other party walks away saying "I transmitted secure data" and 
to them it's over. Playing either role in that situation is bad, but 
being the intelligent admin who cares none for the other guy is worse 
than just saying up front: "This isn't secure, plan accordingly." 


That's not correct in this case though, without MTA-STS (which 
is**rare), it will just be transmitted in plaintext. The "plan 
accordingly" is just gonna be "Ok, I'm gonna tell you anyways".


That aside, it would really take *effort* to configure your MTA to 
provide TLS as bad as plaintext (e.g. null or export ciphersuites), but 
at that point those attacks are kinda your fault. That applies against 
both passive eavesdropping and active attackers. MUAs might be a tad 
different, but those don't support the worst TLS has to offer anyways. 
The weak stuff that is still enabled would still take a while to attack 
or crack.


I mean, it should be fairly obvious that people won't wait until the 
previous iteration gets utterly demolished before switching to the new 
one, they still hold to some extent. This "purism", if one can call it 
that, has kinda made you miss the original goal and lose perspective of 
future improvements.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Disabling TLS 1.0 and 1.1 for MTA to MTA communication

[Taavi Eomäe via mailop]

We were having a discussion on the possibility to disable TLS 1.0 and 
1.1 for MTA to MTA communication, and based on the numbers we've seen 
so far, it doesn't look that far fetched. 
And what about PLAIN - do you still allow that as the fallback option 
or are you also considering disabling that?


Hardening your MTA's TLS configuration and potentially causing TLSv1.0 
and TLSv1.1 clients to fall back to plaintext is counterproductive. The 
first step should really be disabling plaintext.


In parallel to that, if there's a wish to enforce good TLS, how's your 
MTA-STS support? Both incoming and outgoing?



It's already been disabled for our customers towards fx. imap and 
smtp, and we all agree those pesky old versions should be phased out, 
sooner rather than later, but have you also disabled it for MTA to MTA 
communication as well or are you still considering it? And what 
scenarios are currently holding you back?


In theory that's nice, MUAs do tend to be more up-to-date and there 
might be downgrade attacks that this would prevent. *But...*


There's no MUA-STS, most clients are relatively trivially downgrade-able 
(hopefully with /some/ user interaction, but pestering the user tends to 
work). So does that hardening actually help or potentially force some 
old printers (etc.) to stop working or require a plaintext proxy?



[...] pesky old versions should be phased out, sooner rather than 
later [...]


Pesky old versions, what about "new" versions? Do you support TLSv1.3?


Lastly, RFC8314 (re)defines port 465 as implicit TLS SMTP submission 
port. Implicit TLS is considered a significantly better approach than 
upgrading connections. Do you support that?




Wishing you a good day,
Taavi
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] opendkim replacement

[Taavi Eomäe via mailop]

rspamd or WildDuck

On 04/07/2022 05:20, Edwardo Garcia via mailop wrote:


What are we using this days in replace opendkim which is long broken 
abandonware?

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

Re: [mailop] Interesting question from a team member, MX chaining, list-manage.com

[Taavi Eomäe via mailop]

> If you don't want to accept mail for a domain, usually, you'd 
accomplish that by simply not having an MX record.


A nicer way would be to follow RFC7505 and add a null MX record.

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

Re: [mailop] Best practice for mailing list servers

[Taavi Eomäe via mailop]

Hi,

just wondering, wouldn't it be significantly better to only modify 
headers and double-sign when the original message's DKIM signature 
doesn't pass? Absolutely correct me if I'm mistaken, but this would keep 
DMARC (if it also exists) valid and detach the mailing lists' reputation 
from the message, probably making deliverability better. If the senders 
have a proper setup.


ARC on top of that would be a nice clear indication that it has been 
forwarded in some way and DKIM would say it's not lying. The rest of the 
letters' senders can be rewritten.



Or are SPF (hard)fails too strong of a negative signal in most cases 
that these DKIM-signed messages wouldn't be accepted?





Taavi

On 14/06/2022 19:51, Ken O'Driscoll via mailop wrote:

Hi Axel,

I would suggest:

* Make sure that the list's 5321.From (return-path/envelope/MAILFROM) domain 
has a valid and restrictive SPF
* DKIM sign all list messages with your own key
* Use different DKIM keypairs for each list
* Don’t modify the originally message body (e.g., adding in a list footer etc.)
* If the sender's domain has DMARC with an enforcing policy 
(p=quarantine/reject) then rewrite the 5322.From to use the list's domain

Not modifying the body of the message will give any original DKIM message 
signature the best chance of preserving validity.

Signing with your own DKIM key will create an additional reputation data point 
for message filters, which will help over time.

DMARC won't survive a MLM, so you have to rewrite the From to give the message 
a chance of being received. Your own DKIM signature will still be valid.

Implementing ARC wouldn't hurt, but don't expect it to magically fix anything. 
Your ARC set still needs to be trusted by message filters which implement ARC 
and there is no centralised mechanism to facilitate this yet. Larger providers 
may use ML to trust particular ARC header sets but who knows.

I wouldn't suggest that you implement DMARC on your list domain as it won't 
help with deliverability and will just cause more issues. It's not really 
designed for mailing lists.

Ken.


-Original Message-
From: mailop  On Behalf Of Axel Rau via
mailop
Sent: Tuesday 14 June 2022 16:51
To: Paul Vixie via mailop 
Subject: [mailop] Best practice for mailing list servers

Hi all,

I’m running a mailman3 site with several small mailing lists.

Today Google let all mails without DKIM sig bounce.
Other ESPs refuse my mails because of brokem DKIM sig.

Currently the listserver does not DKIM-sign nor remove DKIM-sigs.

It seems, that mails with DKIM-sig (from the author domain, but broken
bei the list server) are accepted by Google.

Should I adopt ARC?
Along with DMARC?

What is best practice in 2022?


Any help appreciated,
Axel
---
PGP-Key: CDE74120  ☀  computing @ chaos claudius

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

___
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] gmail changes today?

[Taavi Eomäe via mailop]

Can confirm, we have seen that as well. Enforcement has slowly ramped up 
for months now. Adding an SPF record (or fixing the hard fail) usually 
remedies the issue.


On 08/06/2022 05:40, William Kern via mailop wrote:

We saw that as well, but some of the cases involved non-existent or malformed 
spf records. When those were fixed Gmail began to accept their emai.

That may have been a timing coincidence but at least we solved a future problem 
for them.

-wk

Sent from my iPad


On Jun 7, 2022, at 6:28 PM, Zube via mailop  wrote:

Looks like something changed at gmail today, at least for us.

Huge swathes of email are being rejected with:

Our system has detected that this message is likely unsolicited mail.

It has nothing to do with the content of the message.  It can be long,
medium or short.  Stuff that I've been sending for years to addresses
I've been sending for years is now marked in this way.

It's also inconsistent.  I have a crontab output that gets sent to a
gmail user 3x a day.  It contains the exact same content each time.
Twice today, no problem.  Third time, bounced as unsolicited mail.
For a while, even messages with just the word "test" were being marked
as such.

Is anyone else seeing similiar behavior today?

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

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


OpenPGP_signature
Description: OpenPGP digital signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop