Re: [mailop] SPF behavior on email forwarding

On Fri, Apr 14, 2023 at 11:20:22AM -0400, John Levine via mailop wrote: > It appears that Jaroslaw Rafa via mailop said: > >Dnia 14.04.2023 o godz. 14:11:49 Slavko via mailop pisze: > >> In other words, SPF check is not something what helps with SPAM > >> here, seems that spammers adapted to

Re: [mailop] SPF behavior on email forwarding

In other words, SPF check is not something what helps with SPAM here, seems that spammers adapted to it... As far as I know, SPF was never meant as an anti-spam measure. It was most definitely touted as an anti-spam measure. Some of us were there. Absolutely. Spent time listening to Meng

Re: [mailop] SPF behavior on email forwarding

Lou Katz via mailop writes: > On Fri, Apr 14, 2023 at 11:20:22AM -0400, John Levine via mailop wrote: >> It appears that Jaroslaw Rafa via mailop said: >> >Dnia 14.04.2023 o godz. 14:11:49 Slavko via mailop pisze: >> >> In other words, SPF check is not something what helps with SPAM >> >> here,

Re: [mailop] SPF behavior on email forwarding

On Fri, Apr 14, 2023 at 11:20:22AM -0400, John Levine via mailop wrote: > It appears that Jaroslaw Rafa via mailop said: > >Dnia 14.04.2023 o godz. 14:11:49 Slavko via mailop pisze: > >> In other words, SPF check is not something what helps with SPAM > >> here, seems that spammers adapted to

Re: [mailop] SPF behavior on email forwarding

On Fri, 14 Apr 2023, John Levine via mailop wrote: SRS never made it into the IETF standards, by the way, because the problem it was supposed to solve (forwarding delayed bounces) did not actually exist. Since today is Friday ... I was just re-reading

Re: [mailop] SPF behavior on email forwarding

Thank you everyone for your messages, I appreciate it and it was very interesting. I think we'll change our behavior to not only stop at SPF failure, but include it in the antispam processing and eventually really block when DMARC is set to reject and fails. We have implemented ARC as a signing

Re: [mailop] SPF behavior on email forwarding

Dňa 14. apríla 2023 17:06:57 UTC používateľ John Levine via mailop napísal: >We also didn't anticipate how always-on connections would become fast >and cheap, disk space would become free, and everyone would use IMAP >so they can handle mail on multiple devices. Once you do that, most of >the

Re: [mailop] SPF behavior on email forwarding

According to Bill Cole via mailop : >1. SPF breaks traditional transparent forwarding, so SPF is wrong and >should be abandoned. >2. Traditional transparent forwarding breaks SPF, so traditional >transparent forwarding is wrong and should be abandoned. >3. Everyone should deploy SRS so there's

Re: [mailop] SPF behavior on email forwarding

On 2023-04-14 at 11:20:22 UTC-0400 (14 Apr 2023 11:20:22 -0400) John Levine via mailop is rumored to have said: It appears that Jaroslaw Rafa via mailop said: Dnia 14.04.2023 o godz. 14:11:49 Slavko via mailop pisze: In other words, SPF check is not something what helps with SPAM here,

Re: [mailop] SPF behavior on email forwarding

On 2023-04-14 at 08:45:20 UTC-0400 (Fri, 14 Apr 2023 14:45:20 +0200) Jaroslaw Rafa via mailop is rumored to have said: It's a well-known fact since SPF appeared, that SPF breaks forwarding. People say nowadays "forwarding breaks SPF", but I prefer to say it the other way, because forwarding

Re: [mailop] SPF behavior on email forwarding

It appears that Jaroslaw Rafa via mailop said: >Dnia 14.04.2023 o godz. 14:11:49 Slavko via mailop pisze: >> In other words, SPF check is not something what helps with SPAM >> here, seems that spammers adapted to it... > >As far as I know, SPF was never meant as an anti-spam measure. It was most

Re: [mailop] SPF behavior on email forwarding

Dnia 14.04.2023 o godz. 14:11:49 Slavko via mailop pisze: > In other words, SPF check is not something what helps with SPAM > here, seems that spammers adapted to it... As far as I know, SPF was never meant as an anti-spam measure. SPF protects against *impersonation*, ie. someone else sending

Re: [mailop] SPF behavior on email forwarding

Dňa 14. apríla 2023 12:56:30 UTC používateľ Andrew C Aitchison via mailop napísal: >Do you have an actual measure of how much spam this is currently blocking ? >It *may* not be as bad as you think. I store them, but not for scientific use - in mean many connections are rejected by some checks

Re: [mailop] SPF behavior on email forwarding

My understanding is that ARC validators have a list of trusted ADMDs (domains) that they trust the ARC results of to be "accurate and true". If the chain is valid at receipt, all of the sealed

Re: [mailop] SPF behavior on email forwarding

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

Re: [mailop] SPF behavior on email forwarding

On Fri, 14 Apr 2023, Cyril - ImprovMX via mailop wrote: Hi! What is the best approach when you receive an email that doesn't respect the SPF (with a hard fail)? I'm asking because we've been running ImprovMX for a few years now and the decision we took was that if you send us an email with a

Re: [mailop] SPF behavior on email forwarding

On 2023-04-14 07:45, Taavi Eomäe via mailop wrote: 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

Re: [mailop] SPF behavior on email forwarding

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

Re: [mailop] SPF behavior on email forwarding

Dnia 14.04.2023 o godz. 13:26:13 Cyril - ImprovMX via mailop pisze: > I'm asking because we've been running ImprovMX for a few years now and the > decision we took was that if you send us an email with a SPF that is > failing ("-a"), we immediately refuse the email. > > For me, the reason was

Re: [mailop] SPF behavior on email forwarding

> On 14 Apr 2023, at 12:26, Cyril - ImprovMX via mailop > wrote: > > Hi! > > What is the best approach when you receive an email that doesn't respect the > SPF (with a hard fail)? > > I'm asking because we've been running ImprovMX for a few years now and the > decision we took was that if

Re: [mailop] SPF behavior on email forwarding

Dňa 14. apríla 2023 11:26:13 UTC používateľ Cyril - ImprovMX via mailop napísal: >What would be the best behavior here? Should we rely on both the SPF AND >DKIM to refuse an email (compared to just the SPF), even if no DMARC are >set? >What is the best approach here? I don't know what is

Re: [mailop] SPF behavior on email forwarding

>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

Re: [mailop] SPF behavior on email forwarding

On 14/04/2023 12:26, Cyril - ImprovMX via mailop wrote: > What is the best approach here? Identify the forwarders your customers are using and for those origins either assume SPF passed or lookup the SPF result in the headers. -- Simon Arlott ___

[mailop] SPF behavior on email forwarding

Hi! What is the best approach when you receive an email that doesn't respect the SPF (with a hard fail)? I'm asking because we've been running ImprovMX for a few years now and the decision we took was that if you send us an email with a SPF that is failing ("-a"), we immediately refuse the