SSL certificates do not, and have never, "protected against MiTM". The certificate authority trust
model can best be summarized as "someone else's DNS resolver and connection", it is not a statement
of who actually owns the domain or what server is actually supposed to be on the other end.
If y
On 10/22/23 9:08 AM, Slavko via mailop wrote:
Dňa 22. októbra 2023 12:50:52 UTC používateľ Philip Paeps
napísal:
Note that, as far as email is concerned, plaintext downgrade attacks are much
more likely than fraudulent certificates.
Hmm, and what about MUAs?
As Philip pointed out, DNS
On 10/23/23 3:26 AM, Jaroslaw Rafa via mailop wrote:
Dnia 22.10.2023 o godz. 12:59:18 Matt Corallo via mailop pisze:
SSL certificates do not, and have never, "protected against MiTM".
The certificate authority trust model can best be summarized as
"someone else's DNS res
On 10/22/23 1:56 PM, Taavi Eomäe via mailop wrote:
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+DN
On 10/23/23 7:11 PM, Richard Clayton via mailop wrote:
In message , Matt
Corallo via mailop writes
On 10/23/23 3:26 AM, Jaroslaw Rafa via mailop wrote:
However, all this discussion is hardly related to email, as - as many have
noted - there's hardly any certificate checking a
On 10/23/23 9:43 PM, Matt Palmer via mailop wrote:
On Mon, Oct 23, 2023 at 10:04:25PM -0400, Ian Kelling via mailop wrote:
Philip Paeps via mailop writes:
On 2023-10-22 14:34:39 (+0530), Slavko via mailop wrote:
Indeed: not directly related to mailops. But a very instructive example
of why
For various reasons, DKIM's non-repudiation property has always prevented us
deploying DKIM signing on our mail. The
obvious fix for this is to roll DKIM keys aggressively (eg every few minutes)
and publish the private keys for revoked
keys as you go. Given relay times for mail through various ho
frequently I've heard
> personally. When I managed this for Amazon SES, I
> think the policy was 6 months or a year.
>
> On Fri, Jul 10, 2020 at 4:39 PM Matt Corallo via mailop <mailto:mailop@mailop.org>> wrote:
>
> For various reasons, DKIM's non-r
On 7/10/20 8:36 PM, Luis E. Muñoz wrote:
> On 10 Jul 2020, at 16:54, Matt Corallo via mailop wrote:
>
> Replies inline.
>
> On 7/10/20 7:50 PM, Brian Toresdahl wrote:
>
> Your approach and goals don't seem to make sense to me.
>
> TL;DR: T
On 7/10/20 8:59 PM, Brandon Long wrote:
>
>
> On Fri, Jul 10, 2020 at 5:39 PM Luis E. Muñoz via mailop <mailto:mailop@mailop.org>> wrote:
>
> __
>
> On 10 Jul 2020, at 16:54, Matt Corallo via mailop wrote:
>
> Replies inline.
>
>
On 7/10/20 9:05 PM, Brandon Long wrote:
> If it was a one-time DKIM key, you could publish it after being read one time
> or with some short timeout. To many
> providers, delivery is a matter of seconds.
>
> Of course, someone could take advantage because the key would be cached up to
> some
Fri, Jul 10, 2020 at 08:57:04PM -0400, Matt Corallo via mailop wrote:
>> Hmm, that may have been confusingly worded, I admit. The point is that
>> we'd like to publish the private keys after delivery. This means that if
>> anyone goes and verifies an email with the DKIM key
Who said anything about it being a legal defense. In discovery you’d have to
give over your local copies anyway, so it’s very clearly not.
> On Jul 10, 2020, at 21:16, John Levine via mailop wrote:
>
> In article <48a3bfbe-5109-ebbb-3631-1bb604cd1...@bluematt.me> you write:
>>>TL;DR: The
Right, maybe I’ve missed something - in my (albeit limited) experience, mail
that gets forwarded a few times by various filters (most recent issue I’ve seen
is someone trying to forward Rackspace -> Gmail -> ZenDesk, which, somewhere
along the way didn’t make it), and without anything tying the
email with someone else the
private key is public and that someone else only sees that the recipient either
received the email or put the email in their inbox using IMAP, but has no idea
which.
Matt
> On Jul 11, 2020, at 08:21, Ralph Seichter via mailop
> wrote:
>
> * Matt Corall
11, 2020, at 07:44, Andrew C Aitchison wrote:
>
> On Fri, 10 Jul 2020, Matt Corallo via mailop wrote:
>
>> For various reasons, DKIM's non-repudiation property has always
>> prevented us deploying DKIM signing on our mail. The obvious fix for
>> this is to roll D
Hmm? SSS/TLS has never signed the content of a website. It only authenticates
temporary symmetric encryption keys which
are used to encrypt (not sign) the contents.
Matt
On 7/11/20 2:50 PM, John Levine wrote:
> In article <22b8aa44-cab8-4467-a18b-ee463997c...@as397444.net> you write:
>> As for u
"Sorry, I think what you're looking for isnt useful, you're misinformed" isn't
exactly a useful response when someone,
especially a customer, asks for something, sadly.
On 7/11/20 3:02 PM, John Levine wrote:
> In article <4ac6b77b-375b-4cc0-b2f5-84f769683...@as397444.net> you write:
>> More like
11 Jul 2020, at 18:18, Matt Corallo via mailop > <mailto:mailop@mailop.org>> wrote:
>>
>> Right, maybe I’ve missed something - in my (albeit limited) experience, mail
>> that gets forwarded a few times by
>> various filters (most recent issue I’ve seen is s
Ah, I didn’t know l= existed, thanks for that! Do most hosts treat l=0 as
DKIM-valid the same way as l=, or are they likely to ignore the DKIM signatures?
Matt
> On Jul 15, 2020, at 07:20, Ángel via mailop wrote:
>
> On 2020-07-11 at 15:27 -0400, Matt Corallo via mailop wrote:
>
Maybe I'm missing something, but I don't see an answer to this question - Ted's
point seems well-made and it seems like
this will retrain users to be more vulnerable to phishing attacks by putting
the correct logo on an unrelated domain.
Matt
On 7/22/20 8:30 PM, Marcel Becker via mailop wrote:
Right, the BIMI website doesn't mention it anywhere, silly me forgot to read
the non-official source :).
On 7/22/20 9:20 PM, Daniel Jakots wrote:
> On Wed, 22 Jul 2020 20:59:54 -0400, Matt Corallo via mailop
> wrote:
>
>> but I don't see an answer to this questi
The standard appears to provide no protection whatsoever, but the specific
implementation announced by Google relies on
CAs to "authenticate" the domains' logo. Seems like there should be a standard
for that, too.
Matt
On 7/22/20 9:17 PM, Ted Hatfield via mailop wrote:
>
>
> On Wed, 22 Jul 20
Good luck.
While its annoying, it seems possible to fix IP blocklists from Microsoft, but everything-from-IP-goes-to-junk seems to
be the default for small volume senders. At least in my attempts at the support webform the only response you get is
"IPs look fine, shouldn't be any issue receivin
If you're a small-scale sender, this is just the way it goes with Outlook.com - SNDS doesn't do anything except provide
you %s, and because the number of emails from small-scale senders is so low (and the "customers" here don't even pay for
the service), Microsoft isn't incentivized to fix the is
As far as I can tell, there's nothing you can do. You can try a non-Hetzner IP, sure, but plenty of people on here (like
me!) have a dedicated IP in their own IP space for sending mail and still go straight to Hotmail-Junk.
Rate limiting might help, but if you send too *few* mails Microsoft's wa
Similarly, I'd love to get a contact with them. Have a domain which appears on one of their lists about every few
months, and after going back and forth a bit on tickets, gets removed every few months, only to have it re-added under
the same bogus justification a few months later. Would be nice t
We had a mistake in a config which resulted in some user From:s on other domains and should have been relayed through
user-configured SMTP relays instead going out directly. Config persisted for all of a few minutes, which is no problem
for other providers, but did result in Outlook completely bl
(new thread cause separate topic)
On 9/20/21 10:29, Brandon Long via mailop wrote:
-snip-
> authenticated mail in reply to a message is a very strong signal... but not
as strong as it used to
> be, spammers
> and phishers exploited it.
Out of curiosity, how does a spammer or phisher exploit thi
Today I was trying to help debug an email list that wasn't properly filtering mail by the
1000-character SMTP line-length limit. This required attaching the original, SMTP-invalid .eml to
send to the postmaster there.
However, it seems MUAs nearly-universally do not handle this correctly. Speci
This happened a little while ago, but still maybe worth posting here. According to [1] and my own
TLS-RPT reports from Microsoft, they're actively enforcing DANE on outbound mails now!
It seems sans one major holdout its finally time to ditch MTA-STS entirely and not bother with the
rube-goldbe
Not to flame but...why bother?
At this point TLSA/DANE is enforced on mail coming from a number of the Big Players, and most open
source mail stacks by default (well, some you have to opt in to indicate your DNSSEC resolver is
behaving correctly).
AFAIK, the *only* shop that enforces the rube
tunistic TLS" provides.
--
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast
-Original Message-
From: mailop On Behalf Of Matt Corallo via
mailop
Sent: Wednesday, April 27, 2022 11:40 PM
To: Jesse Hathaway ; mailop@mailop.org
Subject: [EXTERNAL] Re: [mailop] Troublesh
On 4/28/22 2:34 PM, Michael Ströder via mailop wrote:
On 4/28/22 05:40, Matt Corallo via mailop wrote:
AFAIK, the *only* shop that enforces the rube-goldberg machine that is MTA-STS that doesn't also
enforce TLSA/DANE is Google.
I'm really wondering why people have so strong
> On Apr 28, 2022, at 18:58, Michael Ströder via mailop
> wrote:
>
> On 4/29/22 00:27, Matt Corallo wrote:
>>> On 4/28/22 2:34 PM, Michael Ströder via mailop wrote:
>>> I'm really wondering why people have so strong objections against MTA-STS.
>>> Actually it's pretty easy to setup and it's
Hi, it looks like my Microsoft DMARC Reports are getting spamfiltered by default SpamAssassin,
notably because Spamhaus has listed their origin server in the CSS SBL (among a few other tests).
Should my DMARC reports not go through spam checks? Probably yes, sure. But still, figured I'd
mention
On 7/20/22 3:19 PM, Mark Milhollan via mailop wrote:
On Tue, 19 Jul 2022, Matt Corallo wrote:
Relevant headers below, but note that its actually the very first Received header that matches
SBL-CSS.
You are via Spamassassin doing what Google does and I guess at least some other Spamassassin us
On 7/25/22 3:58 PM, Al Iverson via mailop wrote:
On Mon, Jul 25, 2022 at 2:37 PM Matt Corallo via mailop
wrote:
I don't believe SA does authentication checks on all Received: lines, no, it
only runs them through
the various DNSBLs. I don't see why "you relayed mail from
On 7/25/22 4:31 PM, Al Iverson via mailop wrote:
On Mon, Jul 25, 2022 at 3:25 PM Matt Corallo wrote:
On 7/25/22 3:58 PM, Al Iverson via mailop wrote:
On Mon, Jul 25, 2022 at 2:37 PM Matt Corallo via mailop
wrote:
I don't believe SA does authentication checks on all Received: line
On 7/25/22 4:50 PM, Bill Cole via mailop wrote:
On 2022-07-25 at 15:33:13 UTC-0400 (Mon, 25 Jul 2022 15:33:13 -0400)
There is no useful model for "authenticaton checks" on Received headers.
I believe we're on the same page here. No one is doing "authentication checks" on Received headers,
to
On 8/12/22 6:03 PM, Simon Arlott via mailop wrote:
-snip-
Ideally random outgoing address selection across all IP address
families should be used to avoid this but Exim can't do that.
Sure it can, set your router to include
ipv4_prefer = ${randint:2}
__
Has SpamCop been integrated into the Talos Intelligence handling flow yet? Talos has historically
been one of those "we label everything as bad with a quarter of a braincell so we can tell clients
we've blocked a million billionty attacks for them and they should pay us more" operations, I
imagi
On 10/12/21 10:26, Brandon Long via mailop wrote:
Also, there is a tension in the rfc's here, because you aren't allowed to encode message/rfc822, so
you would have to edit the attached file.
Ah, that's the piece I was missing, explains why no one encodes it and sends
long lines :) Thanks!
43 matches
Mail list logo
