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
__
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 a
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 con
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 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 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 trus
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
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 c
> 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 unt
> 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
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 certifica
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 muc
> 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 pr
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.mailo
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
navig
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 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 see
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 authentica
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 p
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 b
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 descri
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.
sm
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 t
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 p
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 sign
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 th
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
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 seem
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
Consider switching to ipset-s or null routes, both have a lower overhead
than plain iptables rules.
We've tested ipsets with hundreds of thousands of IPs, ipset-s also have
the benefit of supporting entry expiration (timeout).
smime.p7s
Description: S/MIME Cryptographic Signature
__
The best method we've found was to reject all letters with
List-Unsubscribe header (or similar) sent to that victim.
This obviously has side-effects, but they're tolerable compared to the
flood of letters.
I should note that these letters are usually sent in order to cover up
something like
On 09/07/2024 14:27, Kai Bojens via mailop wrote:
I did some research on oauth2 for mail clients as I was thinking about
implementing this feature for our servers. All I could find was that
there is actually no standard for implementing oauth2 for mail
authentication and that the authentication
Hi,
I think the biggest issue with those is that qmail is really dated, the
configuration of the other two is considered difficult and such a setup
likely requires multiple external milters to function properly/securely,
but quite a few commonly used milters for that purpose are unmaintained
On 16/07/2024 14:34, Jeff Pang via mailop wrote:
The new players (5,6,7,8) seem to support well on modern email
standard (DKIM, SPF, DMARC, DANE, MTA-STS). Anyone is using those new
systems?
We are using both WildDuck at a rather respectable scale. We migrated
away from the software at the to
It's likely not great for deliverability (especially if you want letters
from China for example).
Deploying MTA-STS and implicit-TLS ports (465) will probably be your
best bet.
smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop maili
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
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
> 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/listi
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
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?
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 t
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 tr
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 so
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 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 firs
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 rs
Did you encounter such issues in practice and/or were you involved in the
discussion forming that default? If so, it would be nice to get some more
perspective on that.
We see SPF records that exceed the standard's query limit fairly often,
but weren't involved in the forming of rspamd's de
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 u
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
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
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
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.
smim
> 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 spec
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
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],
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
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 yo
>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 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 thi
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
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
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 Crypt
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.
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 Signatur
> 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 Cryptograph
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
> 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 y
> 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 th
On 29/01/2025 14:46, Matus UHLAR - fantomas via mailop wrote:
Is there any kind of DNS error that could cause this?
There was a bug in c-ares recently that caused this in some rare cases.
https://github.com/c-ares/c-ares/issues/757
smime.p7s
Description: S/MIME Cryptographic Signature
On 19/12/2024 02:41, L. Mark Stone via mailop wrote:
Also, again, no disrespect, but I don't see anything wrong with the DNSBL's
suggestion for you to grep your logs for undeliverable outgoing messages within
a certain timeframe. Seems sensible and quite helpful as they've given you a
specifi
On 18/12/2024 16:00, Gellner, Oliver via mailop wrote:
The last two times an IP address which we are responsible for was explicitly
listed by Spamhaus, Spamhaus said that this was due to a misconfiguration in
their side. So we could have searched our logs forever without finding a
malicious me
On 06.05.2025 12:33, Benoit Panizzon via mailop wrote:
It turned out the gmail.com user was forwarding his email to another
recipient which checked our SPF record. As google did not rewrite our
envelope sender in a SRS compatible way, that forwarding failed.
Are these letters DKIM-signed?
Bes
Hi,
On 06.05.2025 13:12, Benoit Panizzon via mailop wrote:
In the google.com case only the Envelope Sender was SPF protected, no
DKIM signature and no DMARC policy published for From Domain
but this seemed to be sufficient in the past.
DKIM has become much more unavoidable in t
On 06.05.2025 13:58, Benoit Panizzon wrote:
If the Recipient only checks SPF and Google does not rewrite the
envelope sender, the Recipient will reject the email. That's what I
concluded yesterday when looking at the issue a customer reported.
The sad thing is that if the final recipient only c
On 12/03/2025 12:23, Winni Neessen via mailop wrote:
I therefore disabled the ED25119 signatures on my end again and only send RSA
signatures, as this seems to be the "universally" accepted signature.
Although I doubt that Ed25519 signatures actually make reputation worse,
but if it did, di
Hi,
On 15.05.2025 08:36, Matthew Tse via mailop wrote:
Is my thinking correct--that we should stop DKIM signing forwarded
emails, and rely on ARC? Also let me know if this is not the right
place or type of question to ask here!
There's no valid reason why you should stop signing, while there
76 matches
Mail list logo
