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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
> 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
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
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
> 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.
> 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
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
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
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
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
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
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
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
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
> 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
> 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
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
> 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
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
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
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
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
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
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
>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
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 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
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
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
> 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
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.
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
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
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
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
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
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
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
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
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
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
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
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
> 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
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
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
61 matches
Mail list logo
