Re: [mailop] hotmail.com SPF forgot IPv6

[Jarland Donnell via mailop]

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 policies: https://datatracker.ietf.org/doc/html/rfc7208


On 2023-08-21 15:17, Gellner, Oliver via mailop wrote:


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 it odd to say that should ignore domain owners 
when they say "-all" since that's a direct and clear request by them.


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.
If someone decides to reject messages from sources listed as 
unauthorized, this is a policy set up by the *receiver*. Fair enough. 
I'm just saying that if the domain owner actually *did* create a policy 
(within the DMARC record, as DMARC allows you to include a policy) and 
this policy says „my messages are authorized as long as they are coming 
from those IP addresses and/or carry a valid cryptographic signature of 
my domain" then I recommend against simply ignoring this policy and 
rejecting messages exclusively based on SPF across the board. This 
might lead to false positives. And one cannot claim that those false 
positives happened on request of the domain owner, when the domain 
owner set up a policy that instructed something different - but the 
receiver ignored it to save some CPU cycles on his box.


--
BR Oliver


dmTECH GmbH
Am dm-Platz 1, 76227 Karlsruhe * Postfach 10 02 34, 76232 Karlsruhe
Telefon 0721 5592-2500 Telefax 0721 5592-2777
dmt...@dm.de * www.dmTECH.de 
[1]

GmbH: Sitz Karlsruhe, Registergericht Mannheim, HRB 104927
Geschäftsführer: Christoph Werner, Martin Dallmeier, Roman Melcher

Datenschutzrechtliche Informationen
Wenn Sie mit uns in Kontakt treten, beispielsweise wenn Sie an unser 
ServiceCenter Fragen haben, bei uns einkaufen oder unser dialogicum in 
Karlsruhe besuchen, mit uns in einer geschäftlichen Verbindung stehen 
oder sich bei uns bewerben, verarbeiten wir personenbezogene Daten. 
Informationen unter anderem zu den konkreten Datenverarbeitungen, 
Löschfristen, Ihren Rechten sowie die Kontaktdaten unserer 
Datenschutzbeauftragten finden Sie 
hier.

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop




Links:
--
[1] http://www.dmTECH.de___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] hotmail.com SPF forgot IPv6

[John Levine via mailop]

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 domain
>owner wishes SPF failure to be treated. I would find it odd to say that should 
>ignore domain owners when they say "-all" since that's a direct and clear 
>request by them.
>
>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.

What's the difference among -all ~all ?all if it's not policy?

(I'm not saying one should pay a lot of attention to the policy, but it's a 
policy.)

R's,
John
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] hotmail.com SPF forgot IPv6

[Gellner, Oliver via mailop]

> 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 
> it odd to say that should ignore domain owners when they say "-all" since 
> that's a direct and clear request by them.

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.
If someone decides to reject messages from sources listed as unauthorized, this 
is a policy set up by the *receiver*. Fair enough. I‘m just saying that if the 
domain owner actually *did* create a policy (within the DMARC record, as DMARC 
allows you to include a policy) and this policy says „my messages are 
authorized as long as they are coming from those IP addresses and/or carry a 
valid cryptographic signature of my domain“ then I recommend against simply 
ignoring this policy and rejecting messages exclusively based on SPF across the 
board. This might lead to false positives. And one cannot claim that those 
false positives happened on request of the domain owner, when the domain owner 
set up a policy that instructed something different - but the receiver ignored 
it to save some CPU cycles on his box.

—
BR Oliver


dmTECH GmbH
Am dm-Platz 1, 76227 Karlsruhe * Postfach 10 02 34, 76232 Karlsruhe
Telefon 0721 5592-2500 Telefax 0721 5592-2777
dmt...@dm.de * www.dmTECH.de
GmbH: Sitz Karlsruhe, Registergericht Mannheim, HRB 104927
Geschäftsführer: Christoph Werner, Martin Dallmeier, Roman Melcher

Datenschutzrechtliche Informationen
Wenn Sie mit uns in Kontakt treten, beispielsweise wenn Sie an unser 
ServiceCenter Fragen haben, bei uns einkaufen oder unser dialogicum in 
Karlsruhe besuchen, mit uns in einer geschäftlichen Verbindung stehen oder sich 
bei uns bewerben, verarbeiten wir personenbezogene Daten. Informationen unter 
anderem zu den konkreten Datenverarbeitungen, Löschfristen, Ihren Rechten sowie 
die Kontaktdaten unserer Datenschutzbeauftragten finden Sie 
hier.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] DKIM AUID and subdomains

[Gellner, Oliver via mailop]

> On 21.08.2023 at 17:57 Slavko via mailop wrote:
>
> Dňa 21. augusta 2023 7:44:45 UTC používateľ Alessandro Vesely via mailop 
>  napísal:
>
>> It is also possible to set:
>>
>> DKIM-Signature: ... d=sub.example.org
>
> Yes, that i used, and that is what i want to avoid -- to maintain separate
> DKIM record/key for any subdomain.

You probably know this, but I’ll mention it nonetheless for other readers: You 
can create CNAME entries for your subdomains or other domains which point to a 
DKIM key. Then you can sign all of the domains with the same key and only 
maintain the keys for your given main domain.

—
BR Oliver



dmTECH GmbH
Am dm-Platz 1, 76227 Karlsruhe * Postfach 10 02 34, 76232 Karlsruhe
Telefon 0721 5592-2500 Telefax 0721 5592-2777
dmt...@dm.de * www.dmTECH.de
GmbH: Sitz Karlsruhe, Registergericht Mannheim, HRB 104927
Geschäftsführer: Christoph Werner, Martin Dallmeier, Roman Melcher

Datenschutzrechtliche Informationen
Wenn Sie mit uns in Kontakt treten, beispielsweise wenn Sie an unser 
ServiceCenter Fragen haben, bei uns einkaufen oder unser dialogicum in 
Karlsruhe besuchen, mit uns in einer geschäftlichen Verbindung stehen oder sich 
bei uns bewerben, verarbeiten wir personenbezogene Daten. Informationen unter 
anderem zu den konkreten Datenverarbeitungen, Löschfristen, Ihren Rechten sowie 
die Kontaktdaten unserer Datenschutzbeauftragten finden Sie 
hier.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] hotmail.com SPF forgot IPv6

[Slavko via mailop]

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 configured OpenDKIM and Python-PolicyD-SPF this way
>myself in the past, I imagine others likely have to, and not
>everybody's smart enough to notice when the edge cases are getting
>weird.
>
>It also depends on whether or not you want to really rely on DMARC or
>not. If so, ~all would stop SPF alone causing a bounce, but still
>leave things up to DMARC as far as rejecting or not ... so DKIM would
>be considered. Assuming it's all configured correctly on the receiving
>side. So, ~all is the way to go given that if done in conjunction with
>DMARC, you're still telling the world to reject faked mail, but in a
>slightly more safe manner.

IMO you are perfectly describe, what i tried to point some time ago.
The sender cannot reliable satisfy both, the receivers doing
standalone SPF (or SPF before DMARC) and receivers doing full
DMARC. If one use -all, then those doing SPF rejects can reject valid
mails with DMARC pass (+DKIM). If one use ~all, those not doing
DMARC will not reject fake senders... And that all just because
checking of SPF is as easy (lightweight).

AFAIK, it is clearly mentioned in DMARC FAQ (don't do SPF action
before DMARC discovery), but for some reason (unknown for me)
that is missing in RFC.

IMO, the DKIM + DMARC is more robust way to prove mail source,
than SPF itself. To satisfy SPF one can simple use own MAIL FROM,
really ease for attacker, more hard in legitime indirect mail flows.

For that, i check standalone SPF at MAIL/RCPT stage only as part
of scoring, and apply it only latter, and only if no DMARC record was
discovered (or if DMARC policy is p=none). In other words i invest
some resources to satisfy, what sender asked. But my MTA is too
small to change anything...

regards


-- 
Slavko
https://www.slavino.sk/
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] DKIM AUID and subdomains

[Slavko via mailop]

Dňa 21. augusta 2023 7:44:45 UTC používateľ Alessandro Vesely via mailop 
 napísal:

>Are you actually moving email addresses to a subdomain?

No, no changes in mail, only in DKIM.

>It is also possible to set:
>
>  DKIM-Signature: ... d=sub.example.org

Yes, that i used, and that is what i want to avoid -- to maintain separate
DKIM record/key for any subdomain.

The per subdomain reputation is not needed, even IMO not wanted, due
low traffic -- IMO nobody will build reputation for ~10 mails per year from
subdomain...

What i was not sure, if the i= is used for something or not. Or if it is know
that someone go behind DKIM and chains d= with From: by same way...

regards


-- 
Slavko
https://www.slavino.sk/
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] hotmail.com SPF forgot IPv6

[Taavi Eomäe via mailop]

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 cases, yes. If there's no 
cryptographically verifiable trust from the origin there isn't a method 
that can make it appear back. SRS and things like SRS just hide it 
(something akin to "trust that we haven't lied about what address we 
rewrote").


That being said, it's way easier for a forwarder not to break DKIM with 
ARC in the mix. It's also easier for the receiver to trust a forwarder's 
ARC seal than it is to trust their SRS (and methods like it). It is a 
bit of a free pass to do a few things naughty, but in those cases the 
original letters were poorly made (unsigned) anyways (and you can also 
treat them accordingly if the letter hasn't been mangled).


You might see benefit from ARC even forwarding email within a single 
organization. Not to mention through multiple forwarders.




smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] hotmail.com SPF forgot IPv6

[Jarland Donnell via mailop]

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 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 it's at, not (only) SPF and SRS-like methods.

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] hotmail.com SPF forgot IPv6

[Al Iverson via mailop]

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.

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 configured OpenDKIM and Python-PolicyD-SPF this way
myself in the past, I imagine others likely have to, and not
everybody's smart enough to notice when the edge cases are getting
weird.

It also depends on whether or not you want to really rely on DMARC or
not. If so, ~all would stop SPF alone causing a bounce, but still
leave things up to DMARC as far as rejecting or not ... so DKIM would
be considered. Assuming it's all configured correctly on the receiving
side. So, ~all is the way to go given that if done in conjunction with
DMARC, you're still telling the world to reject faked mail, but in a
slightly more safe manner.

Cheers,
Al Iverson

-- 

Al Iverson / Deliverability blogging at https://www.spamresource.com
Subscribe to the weekly newsletter at https://ml.spamresource.com
DNS Tools: https://xnnd.com / (312) 725-0130 / Chicago (Central Time)
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [E] Anyone from ATT?

[Lili Crowley via mailop]

Please contact me off list. thanks!

*Lili Crowley*

she/her

Postmaster








On Fri, Aug 18, 2023 at 3:44 PM Judith Villarreal via mailop <
mailop@mailop.org> wrote:

> Hey all. Is anyone from ATT/SbcGlobal on this list? We're having trouble
> with IPs being blocked. Been trying to reach them at
> abuse_...@abuse-att.net but no luck. Thank you so much!
>
> All the best,
> Judith V.
> Delivery and Compliance @ GoDaddy Email Marketing ESP
>
> ___
> mailop mailing list
> mailop@mailop.org
>
> https://urldefense.com/v3/__https://list.mailop.org/listinfo/mailop__;!!Op6eflyXZCqGR5I!C1kvUu_AJr-pF2h0HhptlX3-cmWQZmbVZuQHsE48FIS5MpGtS1VBpU7IDW9OhcT1o6bnxhahsUc3843-A8o$
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] hotmail.com SPF forgot IPv6

[Laurent S. via mailop]

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 
when searching mails.

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] hotmail.com SPF forgot IPv6

[Laura Atkins via mailop]

> 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 transaction, they don’t know what the DMARC domain 
>> is. They can look up DMARC for the domain in the MAIL FROM: but that may 
>> or may not be connected to the actual domain in the 5322.from.
>> 
>> I mean, I think it’s a bad idea to reject for SPF failures, but for 
>> folks who do I can’t imagine they want to see the full content of the 
>> message before just throwing it away. That seems wasteful.
>> 
>> laura
>> 
> 
> 
> Exactly. Also, I don't think that all the scenario where a legitimate 
> mails gets a SPF failure (due to forward/relay for instance) a DKIM will 
> still be good. If they don't care about breaking SPF, I guess they don't 
> care about breaking DKIM either. Avoiding to break SPF isn't rocket science.

I think you misunderstood me. There are lots of straight forwarding situations 
where SPF is broken, but DKIM is intact. I think it’s a poor operational 
decision to block on SPF failure, but I also think it’s a poor operational 
decision to SPF -all. But this is all chickens coming home to roost where folks 
are rejecting wanted mail due to SPF failures. I think it says something that 
we’re almost 20 years into SPF being a thing, and it’s just now where it’s 
causing consequences. Does that mean no one has been enforcing it right? Or 
we’re just now noticing? Or something else completely. 

> We reject on SPF hard failure (-all) after RCPT TO, in order to still 
> let our users welcome list repeat offenders. For this, the sender host 
> (or ip) must have been provided. This works great with mailing-lists and 
> forwards for instance.

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?

laura 

-- 
The Delivery Expert

Laura Atkins
Word to the Wise
la...@wordtothewise.com

Delivery hints and commentary: http://wordtothewise.com/blog






___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] hotmail.com SPF forgot IPv6

[Taavi Eomäe via mailop]

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 it's at, not (only) SPF and SRS-like methods.



smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] hotmail.com SPF forgot IPv6

[Laurent S. via mailop]

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 DMARC for the domain in the MAIL FROM: but that may 
> or may not be connected to the actual domain in the 5322.from.
> 
> I mean, I think it’s a bad idea to reject for SPF failures, but for 
> folks who do I can’t imagine they want to see the full content of the 
> message before just throwing it away. That seems wasteful.
> 
> laura
> 


Exactly. Also, I don't think that all the scenario where a legitimate 
mails gets a SPF failure (due to forward/relay for instance) a DKIM will 
still be good. If they don't care about breaking SPF, I guess they don't 
care about breaking DKIM either. Avoiding to break SPF isn't rocket science.

We reject on SPF hard failure (-all) after RCPT TO, in order to still 
let our users welcome list repeat offenders. For this, the sender host 
(or ip) must have been provided. This works great with mailing-lists and 
forwards for instance.

By the way, hotmail.com still hasn't fixed the issue :-s


___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] hotmail.com SPF forgot IPv6

[Laura Atkins via mailop]

> 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 know this
> 
> You don’t have to ignore domain owners as they do not put any kind of policy 
> into SPF records. SPF does not allow one to to this.
> What domain owners can do is set up a policy in the DMARC record. Of course 
> on the receiver side you can make up any number of additional or even 
> contradictory policies like the one you described, as in „your server, your 
> rules“. But I believe the guidance from M3AAWG which actually takes existing 
> policies from the sender side into account is more friendly and provides less 
> false positives. In a nutshell this means: Do not reject emails based solely 
> on SPF failures as soon as the sending domain has a valid DMARC record.

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 
DMARC for the domain in the MAIL FROM: but that may or may not be connected to 
the actual domain in the 5322.from.

I mean, I think it’s a bad idea to reject for SPF failures, but for folks who 
do I can’t imagine they want to see the full content of the message before just 
throwing it away. That seems wasteful.

laura

-- 
The Delivery Expert

Laura Atkins
Word to the Wise
la...@wordtothewise.com

Delivery hints and commentary: http://wordtothewise.com/blog






___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Anyone a contact @ virusfree.cz

[Josef Vybíhal via mailop]

Hi,
did anyone get back to you? I am listed too and I have asked for
delisting in august 2021. Still listed and reply...

J.

On Tue, 2023-08-15 at 12:29 +0200, Benoit Panizzon via mailop wrote:
> Hi Gang
> 
> virusfree.cz is listing one of our mail servers.
> 
> I opened a support case with them almost two weeks ago to ask for a
> delisting and reason/evidence for the listing.
> 
> They are praised for their good support:
> https://www.virusfree.cz/en/customers-and-support
> 
> Unfortunately I don't get any reaction. Does anyone have a contact to
> them or experience in how they handle such requests?
> 
> Mit freundlichen Grüssen
> 
> -Benoît Panizzon-



smime.p7s
Description: S/MIME cryptographic signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] DKIM AUID and subdomains

[Alessandro Vesely via mailop]

On Sun 20/Aug/2023 12:35:20 +0200 Slavko via mailop wrote:


i recently start to sign subdomain's (no bulk, nor mass, nor advertising,
etc) mails by parent (main) domain key, mostly to simplify DNS setup,
thus mails looks eg.:

 DKIM-Signature: ... d=example.org

 From: 

That works and AFAIK it is permitted/mentioned in RFC and IMO
have to work with DMARC's relaxed alignment.



Are you actually moving email addresses to a subdomain?



Now i think about DKIM identity (i=) tag in signature. I search across
Internet and i found very little (near to zero) info if it is useful. I even
found DKIM ML thread (~10 years old), where it was suggested
to remove it from RFC at all (which doesn't happen).



It is also possible to set:

  DKIM-Signature: ... d=sub.example.org

Here you just have to add a key.  I think reputation is gathered against the 
whole (sub)domain name.  This should result in segmented user reputation, 
perhaps according to the frequency their accounts get compromised...



Best
Ale
--





___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop