> On 21.08.2023 at 22:33 John Levine wrote:
>
> It appears that Gellner, Oliver via mailop said:
>>
SPF contains information about which IP addresses are authorized or
unauthorized to send messages for a given domain. It does not contain a
policy on what to do with this
It appears that Bill Cole via mailop
said:
>> What's the difference among -all ~all ?all if it's not policy?
>
>There's a semantic disconnect here around the word "policy"
>
>The default attribute does not advise anyone what to do, it simply
>expresses a vague judgment by the domain owner of
On 2023-08-21 at 16:33:07 UTC-0400 (21 Aug 2023 16:33:07 -0400)
John Levine via mailop
is rumored to have said:
It appears that Gellner, Oliver via mailop
said:
On 19.08.2023 at 19:01 Jarland Donnell via mailop wrote:
Is "-all" not indeed a policy in SPF, directed by the domain
owner? I
SPF contains information about which IP addresses are authorized or
unauthorized to send messages for a given domain. It does not contain a
policy on what to do with this information.
"Sender Policy Framework"
See G.1-G.4, which are strangely worded for a system that doesn't
contain any
It appears that Gellner, Oliver via mailop said:
>
>> On 19.08.2023 at 19:01 Jarland Donnell via mailop wrote:
>>
>> Is "-all" not indeed a policy in SPF, directed by the domain owner? I would
>> argue that it is. Especially given that there are options there, each one
>> defining how the
> On 19.08.2023 at 19:01 Jarland Donnell via mailop wrote:
>
> Is "-all" not indeed a policy in SPF, directed by the domain owner? I would
> argue that it is. Especially given that there are options there, each one
> defining how the domain owner wishes SPF failure to be treated. I would find
Dňa 21. augusta 2023 14:51:14 UTC používateľ Al Iverson via mailop
napísal:
>The problem is that even if you have DMARC in place, it is VERY easy
>to configure SPF checking so that SPF-failing mail is blocked at the
>edge...you never get far enough to denote DKIM passing. Having
>accidentally
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
ARC is where it's at
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?
On 2023-08-21 04:30, Taavi Eomäe via mailop wrote:
On
Yeah, blocking on SPF -all is scary, really people shouldn't. But I'm
guilty of implementing it that way myself, so who am I to talk? Maybe
it's more that it's fine if you want to do it as a crazy hobbyist, but
if you're one of the biggest mailbox providers on the earth...it's not
a great idea.
On 21.08.23 12:26, Laura Atkins via mailop wrote:
>
> How do your users know to welcome list if the mail is rejected before it
> gets to the user? Do you notify them you rejected mail being sent to
> them or something?
No, we don't notify recipient on reject, but our interface shows rejects
> On 21 Aug 2023, at 10:08, Laurent S. via mailop wrote:
>
>
> On 21.08.23 10:26, Laura Atkins via mailop wrote:
>
>> This recommendation doesn’t make sense. For companies that actually
>> reject due to SPF, they’re most likely going to do it after MAIL FROM:
>> At this point in the
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
On 21.08.23 10:26, Laura Atkins via mailop wrote:
> This recommendation doesn’t make sense. For companies that actually
> reject due to SPF, they’re most likely going to do it after MAIL FROM:
> At this point in the transaction, they don’t know what the DMARC domain
> is. They can look up
> On 19 Aug 2023, at 12:31, Gellner, Oliver via mailop
> wrote:
>
>
>> On 19.08.2023 at 12:30 Benny Pedersen via mailop wrote:
>>
>> prove it, it just loose dmarc aligment, if it was hardfails, lets not ignore
>> domain owners, ever
>>
>> spf softfails can still pass dkim, hopefully you
Dnia 19.08.2023 o godz. 11:49:34 Jarland Donnell via mailop pisze:
>
> Is "-all" not indeed a policy in SPF, directed by the domain owner?
> I would argue that it is. Especially given that there are options
> there, each one defining how the domain owner wishes SPF failure to
> be treated. I
Taavi Eomäe via mailop skrev den 2023-08-19 19:13:
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
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
Is "-all" not indeed a policy in SPF, directed by the domain owner? I
would argue that it is. Especially given that there are options there,
each one defining how the domain owner wishes SPF failure to be treated.
I would find it odd to say that should ignore domain owners when they
say
> On 19.08.2023 at 12:30 Benny Pedersen via mailop wrote:
>
> prove it, it just loose dmarc aligment, if it was hardfails, lets not ignore
> domain owners, ever
>
> spf softfails can still pass dkim, hopefully you know this
You don’t have to ignore domain owners as they do not put any kind of
John Levine via mailop skrev den 2023-08-18 23:37:
Ah! Even better. We are pretty much on the same page then I expect.
There's a whole lot of perfectly normal sending situations that SPF
can't describe. (They mostly incude the words "relay" or "forward".)
So if you reject on -all you'll aways
.
>L. Mark Stone, Founder
>North America's Leading Zimbra VAR/BSP/Training Partner
>For Companies With Mission-Critical Email Needs
>
>- Original Message -
>From: "Mark Alley via mailop"
>To: "mailop"
>Sent: Friday, August 18, 2023 12:06:18 PM
>
Message -
From: "Mark Alley via mailop"
To: "mailop"
Sent: Friday, August 18, 2023 12:06:18 PM
Subject: Re: [mailop] hotmail.com SPF forgot IPv6
Granted, my only point was around message rejection itself with no
consideration for other email authentication conte
;mailop"
Sent: Friday, August 18, 2023 11:15:07 AM
Subject: Re: [mailop] hotmail.com SPF forgot IPv6
Well, if you want to accept the overwhelming amount of DMARC passing mail
signed with DKIM (which these Hotmail messages are, because they are signed
with valid and aligned DKIM)... the
August 18, 2023 10:33:50 AM
Subject: Re: [mailop] hotmail.com SPF forgot IPv6
This will definitely showcase how many receivers are still rejecting based on
SPF failure by itself.
There's already many threads on Reddit about this from regular consumers
experiencing bounces they don't know
VAR/BSP/Training Partner
For Companies With Mission-Critical Email Needs
- Original Message -
From: "Mark Alley via mailop"
To: "mailop"
Sent: Friday, August 18, 2023 10:33:50 AM
Subject: Re: [mailop] hotmail.com SPF forgot IPv6
This will definitely showcase how many
For Companies With Mission-Critical Email Needs
- Original Message -
From: "Mark Alley via mailop"
To: "mailop"
Sent: Friday, August 18, 2023 10:33:50 AM
Subject: Re: [mailop] hotmail.com SPF forgot IPv6
This will definitely showcase how many receivers are still rej
This will definitely showcase how many receivers are still rejecting
based on SPF failure by itself.
There's already many threads on Reddit about this from regular consumers
experiencing bounces they don't know what to do with, it's actually
quite sad reading some of them.
- Mark Alley
On
Aloha hotmail,
It seems since you recently changed your SPF and switched from ~all to
-all. It would have been great if you didn't remove at the same time
your IPv6 ranges from it.
It seems the include:spf.protection.outlook.com was removed during the
change. You might want to include it
29 matches
Mail list logo
