Re: [mailop] SPF fragility vs. utility

a mailop *Sent:* Monday, November 11, 2024 8:48 AM *To:* mailop *Subject:* Re: [mailop] SPF fragility vs. utility On 21.10.2024 at 11:32 Gellner, Oliver via mailop wrote > On 17.10.2024 at 19:43 L. Mark Stone via mailop wrote: >> Back in May at the InboxExpo conference in Atlanta, I was t

Re: [mailop] SPF fragility vs. utility

priorities are mixed. Vlad c/o postmas...@rutgers.edu From: mailop on behalf of Gellner, Oliver via mailop Sent: Monday, November 11, 2024 8:48 AM To: mailop Subject: Re: [mailop] SPF fragility vs. utility On 21.10.2024 at 11:32 Gellner, Oliver via mailop

Re: [mailop] SPF fragility vs. utility

On 21.10.2024 at 11:32 Gellner, Oliver via mailop wrote > On 17.10.2024 at 19:43 L. Mark Stone via mailop wrote: >> Back in May at the InboxExpo conference in Atlanta, I was told by a >> consultant to very large senders that they advise customers to set their >> DMARC to "p=quarantine" because

Re: [mailop] SPF fragility vs. utility

On Mon 21/Oct/2024 16:43:03 +0200 Dave Crocker via mailop wrote: On 10/21/2024 4:39 AM, Alessandro Vesely via mailop wrote: On Mon 21/Oct/2024 05:50:09 +0200 Dave Crocker wrote: In other words, to get around DMARC fragility and false positive damage, an intermediary must  1. Break DMARC, by c

Re: [mailop] SPF fragility vs. utility

On 10/21/2024 4:39 AM, Alessandro Vesely via mailop wrote: On Mon 21/Oct/2024 05:50:09 +0200 Dave Crocker wrote: In other words, to get around DMARC fragility and false positive damage, an intermediary must  1. Break DMARC, by changing the rfc5322.From address to be something other     than

Re: [mailop] SPF fragility vs. utility

On Mon 21/Oct/2024 05:50:09 +0200 Dave Crocker wrote: On 10/18/2024 7:38 AM, Bill Cole via mailop wrote: The real original sender is preserved in the Reply-To here (and on most lists using Mailman today.) In other words, to get around DMARC fragility and false positive damage, an intermediary

Re: [mailop] SPF fragility vs. utility

On 21.10.2024 at 12:14 Lena--- via mailop wrote: >> From: "Gellner, Oliver" >> when I grep Microsoft DMARC reports for temperror, there are hundreds >> of hits. Nevertheless I don't see why you should change your policy >> because one recipients is unable to reliably operate a DNS client. >>

Re: [mailop] SPF fragility vs. utility

> From: "Gellner, Oliver" > when I grep Microsoft DMARC reports for temperror, there are hundreds of > hits. Nevertheless I don't see why you should change your policy because > one recipients is unable to reliably operate a DNS client. > dm-jobs.com > dmglobal4 > temperro

Re: [mailop] SPF fragility vs. utility

On 17.10.2024 at 19:43 L. Mark Stone via mailop wrote: > Back in May at the InboxExpo conference in Atlanta, I was told by a > consultant to very large senders that they advise customers to set their > DMARC to "p=quarantine" because they had been observing that Microsoft's > processing of som

Re: [mailop] SPF fragility vs. utility

Dnia 20.10.2024 o godz. 15:12:08 John Levine via mailop pisze: > >Thunderbird does show more than display names (unless I'm missing something) > >... > > In the message list it just shows the display name unless there is no display > name, > in which case it shows the address. > > When you open

Re: [mailop] SPF fragility vs. utility

On 10/18/2024 7:38 AM, Bill Cole via mailop wrote: The real original sender is preserved in the Reply-To here (and on most lists using Mailman today.) In other words, to get around DMARC fragility and false positive damage, an intermediary must 1. Break DMARC, by changing the rfc5322.From

Re: [mailop] SPF fragility vs. utility

On 20.10.2024 at 04:24 Viktor Dukhovni via mailop wrote:  > On 20 Oct 2024, at 7:09 AM, Gellner, Oliver via mailop > wrote: > > Apple Mail shows Reply-To headers. Not only by default, but always, you > cannot hide them. > The downside is that it does not show the email addresses but only the

Re: [mailop] SPF fragility vs. utility

On 2024-10-20 15:12, John Levine via mailop wrote: It appears that Anthony Howe via mailop said: Similar with Thunderbird. Thunderbird does show more than display names (unless I'm missing something) ... In the message list it just shows the display name unless there is no display name, in

Re: [mailop] SPF fragility vs. utility

It appears that Anthony Howe via mailop said: >> Similar with Thunderbird. > >Thunderbird does show more than display names (unless I'm missing something) >... In the message list it just shows the display name unless there is no display name, in which case it shows the address. When you open

Re: [mailop] SPF fragility vs. utility

On 2024-10-20 14:16, Alessandro Vesely via mailop wrote: On Sun 20/Oct/2024 04:17:22 +0200 Viktor Dukhovni wrote: On 20 Oct 2024, at 7:09 AM, Gellner, Oliver via mailop wrote: Apple Mail shows Reply-To headers. Not only by default, but always, you cannot hide them. The downside is that it do

Re: [mailop] SPF fragility vs. utility

On Sun 20/Oct/2024 04:17:22 +0200 Viktor Dukhovni wrote: On 20 Oct 2024, at 7:09 AM, Gellner, Oliver via mailop wrote: Apple Mail shows Reply-To headers. Not only by default, but always, you cannot hide them. The downside is that it does not show the email addresses but only the display name

Re: [mailop] SPF fragility vs. utility

> On 20 Oct 2024, at 7:09 AM, Gellner, Oliver via mailop > wrote: > > Apple Mail shows Reply-To headers. Not only by default, but always, you > cannot hide them. > The downside is that it does not show the email addresses but only the > display names, both for the From and the Reply-To headers

Re: [mailop] SPF fragility vs. utility

> On 18.10.2024 at 17:08 Slavko via mailop wrote: > > Dňa 18. októbra 2024 14:38:42 UTC používateľ Bill Cole via mailop > napísal: >> On 2024-10-18 at 10:24:05 UTC-0400 (Fri, 18 Oct 2024 14:24:05 +) >> Slavko via mailop >> is rumored to have said: >> >> [...] >>> BTW, this ML is exact exa

Re: [mailop] SPF fragility vs. utility

On Fri 18/Oct/2024 19:33:41 +0200 Jaroslaw Rafa wrote: Dnia 18.10.2024 o godz. 14:24:05 Slavko via mailop pisze: Of course, and spammers would be stupid to not abuse the fact, that email client allow to setup to show display name without email address, with fallback to email, if there is no

Re: [mailop] SPF fragility vs. utility

Hello folks Could we keep the list on track please - mail operations, not browser choice, certificate errors, webserver response codes and so on. Thanks! Graeme ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop

Re: [mailop] SPF fragility vs. utility

Dnia 18.10.2024 o godz. 14:24:21 Bill Cole via mailop pisze: > > It's been a while since I checked, but it used to be that a web > server could instruct the browser to display any URL by setting the > Location header (but NOT refreshing.) You mean response code 200 with a Location: header? Never

Re: [mailop] SPF fragility vs. utility

On 2024-10-18 at 13:57:57 UTC-0400 (Fri, 18 Oct 2024 19:57:57 +0200) Jaroslaw Rafa via mailop is rumored to have said: Dnia 18.10.2024 o godz. 13:51:10 Michael Orlitzky via mailop pisze: On Fri, 2024-10-18 at 19:33 +0200, Jaroslaw Rafa via mailop wrote: I don't understand why anybody is develo

Re: [mailop] SPF fragility vs. utility

On 2024-10-18 at 13:33:41 UTC-0400 (Fri, 18 Oct 2024 19:33:41 +0200) Jaroslaw Rafa via mailop is rumored to have said: [...] Does anybody have any reasonable explanation for that? Some 3rd-rate maintenance engineer at MS assigned to Outlook needed to have a deliverable for his quarterly rem

Re: [mailop] SPF fragility vs. utility

Dnia 18.10.2024 o godz. 13:51:10 Michael Orlitzky via mailop pisze: > On Fri, 2024-10-18 at 19:33 +0200, Jaroslaw Rafa via mailop wrote: > > I don't understand why anybody is developing such stupid mail clients that > > display either one or the other, or do any transformations on the From: > > hea

Re: [mailop] SPF fragility vs. utility

On Fri, 2024-10-18 at 19:33 +0200, Jaroslaw Rafa via mailop wrote: > I don't understand why anybody is developing such stupid mail clients that > display either one or the other, or do any transformations on the From: > header at all, instead of just displaying it as is... > > Does anybody have an

Re: [mailop] SPF fragility vs. utility

Dnia 18.10.2024 o godz. 13:46:07 Slavko via mailop pisze: > AFAIK, the SPF, DKIM nor DMARC never had SPAM as goal. They all (together > or standalone), from my point of vie, did significant drop of simple fake > sender > usage, in mean, if one's bank implements (properly) them and you will check >

Re: [mailop] SPF fragility vs. utility

Dnia 18.10.2024 o godz. 14:24:05 Slavko via mailop pisze: > > Of course, and spammers would be stupid to not abuse the > fact, that email client allow to setup to show display name > without email address, with fallback to email, if there is no > DN. How one then have to distinguish it? > > Here,

Re: [mailop] SPF fragility vs. utility

Dňa 18. októbra 2024 14:38:42 UTC používateľ Bill Cole via mailop napísal: >On 2024-10-18 at 10:24:05 UTC-0400 (Fri, 18 Oct 2024 14:24:05 +) >Slavko via mailop >is rumored to have said: > >[...] >> BTW, this ML is exact example how bad it is, as i setup >> to show email, but here i lost to s

Re: [mailop] SPF fragility vs. utility

On 10/18/2024 6:16 AM, Paul Smith* via mailop wrote: A valid SPF does not indicate it is not spam. This is worth emphasizing.  Some others have also pointed this out, but it still is often missed: If a an identifier is authenticated with a stream of messages, then that stream of messages c

Re: [mailop] SPF fragility vs. utility

On 18/10/2024 15:00, Hans-Martin Mosner via mailop wrote: Am 18.10.24 um 15:16 schrieb Paul Smith* via mailop: A spammer can send SPF-authenticated mail 'From: "b...@microsoft.com" ', but any spam filtering knows that it's not really from Microsoft. What they actually do is register a domai

Re: [mailop] SPF fragility vs. utility

On 2024-10-18 at 10:24:05 UTC-0400 (Fri, 18 Oct 2024 14:24:05 +) Slavko via mailop is rumored to have said: [...] BTW, this ML is exact example how bad it is, as i setup to show email, but here i lost to see, who was sender, and if someone do not add signature... ;-) The real original sen

Re: [mailop] SPF fragility vs. utility

Dňa 18. októbra 2024 14:00:30 UTC používateľ Hans-Martin Mosner via mailop napísal: >What they actually do is register a domain "micorsoft.com", send >SPF-authenticated mail 'From: "b...@microsoft.com" ', and >neither spam filtering software (which doesn't see the similarity) nor the >human v

Re: [mailop] SPF fragility vs. utility

Am 18.10.24 um 15:16 schrieb Paul Smith* via mailop: A spammer can send SPF-authenticated mail 'From: "b...@microsoft.com" ', but any spam filtering knows that it's not really from Microsoft. What they actually do is register a domain "micorsoft.com", send SPF-authenticated mail 'From: "b..

Re: [mailop] SPF fragility vs. utility

Dňa 18. októbra 2024 12:09:01 UTC používateľ Jaroslaw Rafa via mailop napísal: >That's the most important point against SPF, DKIM and DMARC. If they don't >stop spam at all, and are quite limited in preventing forged emails (plus >give a lot of trouble with FPs), are they really still worth push

Re: [mailop] SPF fragility vs. utility

On 18/10/2024 13:09, Jaroslaw Rafa via mailop wrote: Dnia 18.10.2024 o godz. 10:20:46 Hans-Martin Mosner via mailop pisze: In any case, spammers aren't dumb, and they can set up perfectly valid SPF and DKIM for their domains conveniently hidden behind That's the most important point against SPF

Re: [mailop] SPF fragility vs. utility

Yep, that's what backscatter is, isn't it? Groetjes, Louis Op donderdag 17 oktober 2024 om 17:21, schreef Gellner, Oliver via mailop : > On 17.10.2024 at 17:11 Louis via mailop [mailop@mailop.org]> wrote: > > >> Wouldn't backscatter spamming already currently work

Re: [mailop] SPF fragility vs. utility

Dnia 18.10.2024 o godz. 10:20:46 Hans-Martin Mosner via mailop pisze: > In any case, spammers aren't dumb, and they can set up perfectly > valid SPF and DKIM for their domains conveniently hidden behind > domain registrars and hosters who would rather bite and swallow > their tongue than disclose w

Re: [mailop] SPF fragility vs. utility

Yeah, that's true. A lot take SPF as an indicator instead of a hard policy. Even then, it'd be stupid to send a bounce to an SPF hard failed return address, so backscatter is still limited. Groetjes, Louis Op donderdag 17 oktober 2024 om 18:23, schreef Mark Milhollan via mailop : > On Thu, 17

Re: [mailop] SPF fragility vs. utility

On 10/17/2024 10:00 AM, Alessandro Vesely via mailop wrote: Missing a backup authentication method would make DMARC even less reliable. On 17.10.24 17:18, Dave Crocker via mailop wrote: A backup method that adds complexity and breaks under significant, common scenarios does not sound like a gr

Re: [mailop] SPF fragility vs. utility

Am 17.10.24 um 19:42 schrieb L. Mark Stone via mailop: Back in May at the InboxExpo conference in Atlanta, I was told by a consultant to very large senders that they advise customers to set their DMARC to "p=quarantine" because they had been observing that Microsoft's processing of some emails

Re: [mailop] SPF fragility vs. utility

panies With Mission-Critical Email Needs - Original Message - | From: "Alessandro Vesely via mailop" | To: "mailop" | Sent: Thursday, October 17, 2024 1:00:09 PM | Subject: Re: [mailop] SPF fragility vs. utility | On Wed 16/Oct/2024 18:00:47 +0200 Dave Crocker via mai

Re: [mailop] SPF fragility vs. utility

On 10/17/2024 10:00 AM, Alessandro Vesely via mailop wrote: Missing a backup authentication method would make DMARC even less reliable. A backup method that adds complexity and breaks under significant, common scenarios does not sound like a great backup method. Hence my continuing query

Re: [mailop] SPF fragility vs. utility

On Wed 16/Oct/2024 18:00:47 +0200 Dave Crocker via mailop wrote: [...] 7. The myth that SPF is simple to implement is because it is simple for a sender to create a basic SPF record.  It does not mean that it is simple to create a more elaborate record, or to ensure that all authorized sending

Re: [mailop] SPF fragility vs. utility

On Thu, 17 Oct 2024, Louis wrote: If spammers were to use my email in the return path/envelope from with the intent on causing backscatter, the emails will be rejected at SMTP time due to SPF failure. FYI, You might not believe it but not everyone checks SPF much less at SMTP time. They may

Re: [mailop] SPF fragility vs. utility

On 10/16/2024 3:43 PM, Louis via mailop wrote: DKIM+DMARC do not verify the return address. So backscatter spamming would get more attractive to spammers, From this sub-thread, I think I believe that simple use of SPF can be useful for reducing back-scatter. But this has nothing to do with

Re: [mailop] SPF fragility vs. utility

Dnia 17.10.2024 o godz. 15:09:45 Gellner, Oliver via mailop pisze: > > How? Do you block port 80, and for HTTPS intercept their web connections > > using some man-in-the-middle box and filter them? > > You can modify the browser settings to disable http or remove the override > button on the certi

Re: [mailop] SPF fragility vs. utility

On 17.10.2024 at 17:11 Louis via mailop wrote: >> Wouldn't backscatter spamming already currently work the same way with >> messages where the return path address does not align, or with completely >> unauthenticated messages? > If spammers were to use my email in the

Re: [mailop] SPF fragility vs. utility

On 17.10.2024 at 14:52 Jaroslaw Rafa via mailop wrote: > Dnia 17.10.2024 o godz. 12:24:02 Gellner, Oliver via mailop pisze: >> >> Not really. Our regular users are not allowed to connect to sites via >> http or with invalid certificates. Endusers hardly encounter websites >> with certificate err

Re: [mailop] SPF fragility vs. utility

> Wouldn't backscatter spamming already currently work the same way with > messages where the return path address does not align, or with completely > unauthenticated messages? If spammers were to use my email in the return path/envelope from with the intent on causing backscatter, the emails will

Re: [mailop] SPF fragility vs. utility

Dnia 17.10.2024 o godz. 12:24:02 Gellner, Oliver via mailop pisze: > > Not really. Our regular users are not allowed to connect to sites via http > or with invalid certificates. Endusers hardly encounter websites with > certificate errors. How? Do you block port 80, and for HTTPS intercept their

Re: [mailop] SPF fragility vs. utility

On 17.10.2024 at 01:08 Jaroslaw Rafa via mailop wrote: > Dnia 16.10.2024 o godz. 15:12:00 Brandon Long via mailop pisze: >> "big browsers require valid certificates" with no "measurable" >> improvements... > Wrong. You can still connect to a site with invalid certificate or just using > plain H

Re: [mailop] SPF fragility vs. utility

On 17.10.2024 at 00:44 Louis via mailop wrote: > If SPF were deprecated, was would be the actual, significant effects on email > anti-abuse processes? > • DKIM+DMARC do not verify the return address. So backscatter spamming would > get more attractive to spammers, unless every receiver implemen

Re: [mailop] SPF fragility vs. utility

Dnia 16.10.2024 o godz. 15:12:00 Brandon Long via mailop pisze: I'd think "able to send mail to receiver foo" vs not is a measurable improvement. On 17.10.24 01:07, Jaroslaw Rafa via mailop wrote: Only because that receiver arbitrarily decided that they will not accept mail that doesn't meet s

Re: [mailop] SPF fragility vs. utility

> On 16 Oct 2024, at 19:22, Michael Orlitzky via mailop > wrote: > > On Wed, 2024-10-16 at 16:00 +, Dave Crocker via mailop wrote: >> >> 7. The myth that SPF is simple to implement is because it is simple for >> a sender to create a basic SPF record. It does not mean that it is >> simp

Re: [mailop] SPF fragility vs. utility

On Wed, 16 Oct 2024 at 21:41, Michael Orlitzky via mailop wrote: > > The killer feature of SPF is that I can tell somebody how to set it up > over the phone. Most small businesses send mail from one or two places, > and usually, I can google the appropriate "include:" for them. Once SPF > is passi

Re: [mailop] SPF fragility vs. utility

Dnia 16.10.2024 o godz. 15:12:00 Brandon Long via mailop pisze: > I'd think "able to send mail to receiver foo" vs not is a measurable > improvement. Only because that receiver arbitrarily decided that they will not accept mail that doesn't meet some arbitrary criteria imposed by them. Of course

Re: [mailop] SPF fragility vs. utility

> If SPF were deprecated, was would be the actual, significant effects on email > anti-abuse processes? * DKIM+DMARC do not verify the return address. So backscatter spamming would get more attractive to spammers, unless every receiver implemented some form of BATV. Which would be yet anoth

Re: [mailop] SPF fragility vs. utility

On Wed, Oct 16, 2024 at 2:22 PM Jaroslaw Rafa via mailop wrote: > Dnia 16.10.2024 o godz. 15:03:19 Michael Orlitzky via mailop pisze: > > > 2. The benefit you cite is the usual one for the sender, but a) it > > > ignores issues with receivers, and b) it ignores multi-hop scenarios. > > > > What i

Re: [mailop] SPF fragility vs. utility

Dnia 16.10.2024 o godz. 15:03:19 Michael Orlitzky via mailop pisze: > > 2. The benefit you cite is the usual one for the sender, but a) it > > ignores issues with receivers, and b) it ignores multi-hop scenarios. > > What issues? A priori, recipients ignore it. It doesn't get much easier > than t

Re: [mailop] SPF fragility vs. utility

On Wed, Oct 16, 2024 at 11:32 AM Slavko via mailop wrote: > Dňa 16. októbra 2024 18:13:45 UTC používateľ Brandon Long via mailop < > mailop@mailop.org> napísal: > > >The general theory is that a replay involves mail for a DKIM domain > >coming from different sources/hops than it normally does. H

Re: [mailop] SPF fragility vs. utility

On Wed, 2024-10-16 at 18:44 +, Dave Crocker wrote: > On 10/16/2024 11:22 AM, Michael Orlitzky via mailop wrote: > > The killer feature of SPF is that I can tell somebody how to set it up > > over the phone. Most small businesses send mail from one or two places, > > and usually, I can google th

Re: [mailop] SPF fragility vs. utility

On 10/16/2024 11:22 AM, Michael Orlitzky via mailop wrote: The killer feature of SPF is that I can tell somebody how to set it up over the phone. Most small businesses send mail from one or two places, and usually, I can google the appropriate "include:" for them. Once SPF is passing, whitelistin

Re: [mailop] SPF fragility vs. utility

On 10/16/2024 11:13 AM, Brandon Long via mailop wrote: he general theory is that a replay involves mail for a DKIM domain coming from different sources/hops than it normally does. Having spf/dkim both align is usually a good indication that a message is not a replay, ahh, that makes sense. 

Re: [mailop] SPF fragility vs. utility

On Wed, 2024-10-16 at 16:00 +, Dave Crocker via mailop wrote: > > 7. The myth that SPF is simple to implement is because it is simple for > a sender to create a basic SPF record.  It does not mean that it is > simple to create a more elaborate record, or to ensure that all > authorized send

Re: [mailop] SPF fragility vs. utility

Dňa 16. októbra 2024 18:13:45 UTC používateľ Brandon Long via mailop napísal: >The general theory is that a replay involves mail for a DKIM domain >coming from different sources/hops than it normally does. Having spf/dkim >both align >is usually a good indication that a message is not a replay,

Re: [mailop] SPF fragility vs. utility

On Wed, Oct 16, 2024 at 11:04 AM Dave Crocker wrote: > > On 10/16/2024 10:55 AM, Brandon Long via mailop wrote: > > The most meaningful utility of SPF at the moment I think is to help > > identify DKIM replay cases. > > I have tried to track the DKIM replay discussions, but do not recall > seeing

Re: [mailop] SPF fragility vs. utility

On 10/16/2024 10:55 AM, Brandon Long via mailop wrote: The most meaningful utility of SPF at the moment I think is to help identify DKIM replay cases. I have tried to track the DKIM replay discussions, but do not recall seeing a reference to SPF's being useful for this.  Can you elaborate?

Re: [mailop] SPF fragility vs. utility

On Wed, Oct 16, 2024 at 9:04 AM Dave Crocker via mailop wrote: > While SPF is entrenched, and challenges to its use typically gets a > casual claim that it provides incremental benefit where DKIM fails, I > believe there is no published data demonstrating that the incremental > benefit is real an

[mailop] SPF fragility vs. utility

Folks, Good morning.  Take a breath and try this with a cup of coffee or tea... 1. The more features a specification has, the more opportunity for an implementer to make an error, starting with the potential misreading or ambiguities in the specification text.  Also, the more expensive to do