Re: [mailop] Rolling DKIM Key Disclosure

In article <48a3bfbe-5109-ebbb-3631-1bb604cd1...@bluematt.me> you write: >> TL;DR: The customer is always right, and the customer sees DKIM being >> used regularly to authenticate leaked >emails - if >> old not-in-use keys are public, anyone can sign anything they want, and >> suddenly yo

Re: [mailop] Rolling DKIM Key Disclosure

On 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 *after* delivery, they

Re: [mailop] Rolling DKIM Key Disclosure

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

Re: [mailop] Rolling DKIM Key Disclosure

On Fri, Jul 10, 2020 at 5:59 PM Matt Corallo via mailop wrote: > > > 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

Re: [mailop] Rolling DKIM Key Disclosure

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 > wrote: > > __ > > On 10 Jul 2020, at 16:54, Matt Corallo via mailop wrote: > > Replies inline. > > On 7/10/20 7:50 PM, Brian Toresdahl

Re: [mailop] Rolling DKIM Key Disclosure

On Fri, Jul 10, 2020 at 5:39 PM Luis E. Muñoz via mailop 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: The customer is always right, and th

Re: [mailop] Rolling DKIM Key Disclosure

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: The customer is always right, and t

Re: [mailop] Rolling DKIM Key Disclosure

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: The customer is always right, and the customer sees DKIM being used regularly to authenticate leaked emails -

Re: [mailop] Intermittent slow email delivery

On 2020-07-10 at 14:36 -0700, Job Cacka wrote: > There is PAT firewall that load balances multiple networks. > A Barracuda spam filter > And then the MX server. > > > It was working well until about 6-8 weeks ago when we began to notice > the intermittent issue. > > > Thanks, > Job I would ha

Re: [mailop] Rolling DKIM Key Disclosure

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: The customer is always right, and the customer sees DKIM being used regularly to authenticate leaked emails - if old not-in-use keys are public, anyone can sign anything th

Re: [mailop] Rolling DKIM Key Disclosure

Your approach and goals don't seem to make sense to me. DKIM works (I'm summarizing a lot) by signing mail, and the public key to check that signature is placed in a "selector" record in DNS (selector1._ domainkeys.example.com). If you want to rotate DKIM keys, you can immediately start signing ne

[mailop] Rolling DKIM Key Disclosure

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

Re: [mailop] Intermittent slow email delivery

On 10 Jul 2020, at 14:36, Job Cacka via mailop wrote: There is PAT firewall that load balances multiple networks. Hopefully not a descendant of a PIX. I've never have had happy stories involving [NP]AT and SMTP servers. I tend to go with what others have said: The fw might be trying to r

Re: [mailop] Intermittent slow email delivery

On Fri, 10 Jul 2020 at 23:36, Job Cacka via mailop wrote: > > There is PAT firewall that load balances multiple networks. Maybe one of those destination networks is unreachable, while others are reachable, so when the load-balancing decision points to the unreachable network, the TCP session will

Re: [mailop] Intermittent slow email delivery

I checked my ISP and they wrap it in a vlan and hand it off to us, so that is fine. On the firewall I noticed several high volume rules that were logging since 2018 and turned them off in case it was causing an issue. Looking at PAT/NAT we are translating in bound and outbound traffic so that sho

Re: [mailop] Intermittent slow email delivery

On 7/10/20 14:36, Job Cacka via mailop wrote: There is PAT firewall that load balances multiple networks. This is a possibility, especially if the load-balancing is pushing some incoming traffic to the wrong internal network. A Barracuda spam filter If this is configured to drop traffic b

Re: [mailop] Intermittent slow email delivery

There is PAT firewall that load balances multiple networks. A Barracuda spam filter And then the MX server. It was working well until about 6-8 weeks ago when we began to notice the intermittent issue. Thanks, Job On Fri, Jul 10, 2020, 12:30 PM Luis E. Muñoz via mailop wrote: > On 10 Jul 2020,

Re: [mailop] Intermittent slow email delivery

Right. So where should I begin? Firewall says it passes all traffic. Next would be Barracuda it doesn't show any drops. I suppose on the server I could look at tcpdump. Thanks! Job On Fri, Jul 10, 2020, 11:26 AM Jay Hennigan via mailop wrote: > On 7/10/20 11:06, Job Cacka via mailop wrote:

Re: [mailop] Intermittent slow email delivery

On 10 Jul 2020, at 9:47, Adam D. Barratt via mailop wrote: On Fri, 2020-07-10 at 09:22 -0700, Job Cacka via mailop wrote: slowmailtest...@ccbox.com slowmailtest...@ccbox.com slowmailtest...@p-r-c.com slowmailtest...@p-r-c.com From a quick test, at least half of connections get immediately

Re: [mailop] [EXTERNAL] Re: Post-processing Journal-Mails coming from O365, forwardedMail

That sample has NOTHING about what we thought about the sample. It’s all pre-filter, pre-verdict, pre … just about everything. It’s useless from a diagnostic POV. Aloha, Michael. -- Michael J Wise Microsoft Corporation| Spam Analysis "Your Spam Specimen Has Been Processed." Open a ticket for Hot

Re: [mailop] Intermittent slow email delivery

On 7/10/20 11:06, Job Cacka via mailop wrote: "Senders will tend to back off, and retry at increasingly long intervals, until they get a successful connection." Thanks for the test Adam. I do agree with your Analysis. The interesting thing is I am not seeing this refusal at my end logged. Perha

Re: [mailop] Intermittent slow email delivery

"Senders will tend to back off, and retry at increasingly long intervals, until they get a successful connection." Thanks for the test Adam. I do agree with your Analysis. The interesting thing is I am not seeing this refusal at my end logged. Perhaps it never made it to the maillog and that is ho

Re: [mailop] Intermittent slow email delivery

On Fri, 2020-07-10 at 09:22 -0700, Job Cacka via mailop wrote: > slowmailtest...@ccbox.com > slowmailtest...@ccbox.com > > slowmailtest...@p-r-c.com > slowmailtest...@p-r-c.com From a quick test, at least half of connections get immediately rejected, which probably isn't helping: adam@kotick:$

Re: [mailop] Intermittent slow email delivery

Hmmm, for some reason I need to "Reply All" in Gmail to reply to the list. Try two. "You have no logs, and provide little to no detail." Correct, and if it wasn’t a problem I wouldn’t even see the issue. I only have a few message headers to go off of because the sender is experiencing the “temp

[mailop] Pinging Mimecast

Mimecast is apparently sending from 185.58.84.0/24 (specifically eu-smtp-delivery-42.mimecast.com / 185.58.84.42). This is not included in what customers apparently have in their SPF records ("include:eu._netblocks.mimecast.com" and "include:us._netblocks.mimecast.com“), with the obvious resul

Re: [mailop] Does anyone have experience with Gmail lockouts?

Thanks for all the insight thus far! @Brian - Thanks for the suggestion. I will definitely see if this client can upgrade their plan. They definitely have some strategy issues that will need to be addressed. Just as you said, documentation is limited to none so getting some reinforcement from the

Re: [mailop] Digital Ocean Broken Bot attack, just in case it's you and not me..

Hello! On Thu, 9 Jul 2020, Benoit Panizzon via mailop wrote: Range, 192.241.227.0/24 One connect each on Thu, Sat, Sun, and Mon. Did EHLO after banner, then closed the connection. 116 connections between 27. June and 1. July to my spamtrap / honeypot, mostly sending "EHLO zg-0626-127" and

Re: [mailop] Does anyone have experience with Gmail lockouts?

> On 9 Jul 2020, at 22:57, Nathan She via mailop wrote: > > Hey everyone, > > A client of ours is seeing their sales reps and account managers locked out > of their G-suite accounts. Upon trying to log in, they get the message “It > looks like this account was used in a way that violated Goo