Re: [mailop] Microsoft Office365 not rejecting emails when instructed so by SPF recored?

[Byung-Hee HWANG via mailop]

> (...) 
> If you ask me - a better solution would be to do away with forwarding
> completely and incorporate POP checks, like Gmail does.  This alleviates
> all of the issues with forwarding mail in relation to SPF and DKIM.
> (...) 

There are sevral projects using forwarding. The Debian Project is it.
Also i use forwarding very heavy. All debian bug dist messages come to
me (soyeo...@doraji.xyz -> soyeomul+...@gmail.com) via forwarding. 

You check this[1]:
[1] https://gitlab.com/soyeomul/Gnus/-/raw/master/DKIM/setup-policy.lua


Sincerely, Byung-Hee


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

Re: [mailop] Microsoft Office365 not rejecting emails when instructed so by SPF recored?

[John Levine via mailop]

It appears that Brandon Long via mailop  said:
>Unlike SPF, DKIM was only authentication, not policy.  The policy portion
>was attempted via ADSP, but it suffered from the point that few enough
>people implemented DKIM and how to handle the cases where the message was
>modified.

ADSP was a preview of everything that is bad about DMARC. I made the
strictest level "discardable", to make it clear that it's for
unimportant mail. My co-authors hated that but had to admit it was
correct. I also predicted that most of the people who published ADSP
policies would have no idea what they were doing, which turned out to
be correct.

Around the time it was published, some eager beaver added ADSP to his
mail server and for some reason decided "discardable" meant to reject
the message. So of course IETF mailing lists broke the DKIM sigatures,
he rejected all the discardable messages and bounced himself off a
bunch of lists.

Once people realized what had happened, there was no further interest
in ADSP that I can recall.

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

Re: [mailop] Microsoft Office365 not rejecting emails when instructed so by SPF recored?

[John Levine via mailop]

It appears that Scott Mutter via mailop  said:
>But I know that stance is wildly unpopular since it breaks the "it used to
>work that way" narrative. ...

No, it's wildly unpopular because it is blaming the victim.

You might as well also say that every mailing list should shut down in favor
of Tiktok threads, since that's what all the kewl kids do now.

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

Re: [mailop] why some ISP domains have no spf?

[Gellner, Oliver via mailop]

> On 26.05.2023 at 10:10 Ken Peng via mailop wrote:
>
> Why some huge ISPs do not even have SPF for their sending domains?
> such as att.net and t-online.de.
> I know they may let their users to send email from home DSL via (no-auth) 
> relay servers, but since the IPs (no matter relay server or home IP) are 
> assigned by them, it's not hard a job for them to have SPF configured.
> for example, t-online's another domain: magenta.de, does have SPF setup.

I can’t speak for att.net, but t-online.de writes on their Postmaster page:

„The Sender Policy Framework, SPF for short, can enable a check to determine 
whether the sending IP address is authorized to send e-mails for the domain in 
question. This procedure has numerous vulnerabilities that cannot be 
compensated for, including those that are described here 
(https://en.wikipedia.org/wiki/Sender_Policy_Framework). Therefore, Telekom 
does not use SPF either passively (when receiving e-mails) or actively (for 
sending) by creating corresponding DNS resources.“

Not evaluating SPF is probably not a big problem for them, as they only accept 
emails from whitelisted servers (which is an actual problem for the email 
ecosystem).
Another reason that they do not support SPF together with DKIM and DMARC might 
be that they want to sell a a product named Trusted Dialog, which is very 
similar to those standards coupled with BIMI, except that you must pay them 
money to have them evaluate your signature.

—
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] Microsoft Office365 not rejecting emails when instructed so by SPF recored?

[Scott Mutter via mailop]

On Fri, May 26, 2023 at 12:34 PM Brandon Long  wrote:

> When forwarding mail, there are two options: rewrite the envelope sender
> or not.  There are a variety of pros and cons to both of them, and cases
> where one or the other is more prominent.  Not rewriting has been the
> dominant form of 1:1 forwarding such as aliases and address migration, and
> enforcing SPF -all would break that use case.
>

If you ask me - a better solution would be to do away with forwarding
completely and incorporate POP checks, like Gmail does.  This alleviates
all of the issues with forwarding mail in relation to SPF and DKIM.

But I know that stance is wildly unpopular since it breaks the "it used to
work that way" narrative.  But at some point you add so much to a system
that it becomes so bloated and overloaded that nothing can be
accomplished.  The more simple a system is the more efficient it is going
to be.  Outside of external mail server forwarders, a properly constructed
SPF record can go a long, long way towards alleviating the spam problem.
How much is it worth to keep external forwarders working at the cost of
spam prevention?  If forwarding mail is so important, can a better system
for handling forwarded mail be developed?  I'm just not sure if the answer
is to continue to add systems and directives to email to solve all of this.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Microsoft Office365 not rejecting emails when instructed so by SPF recored?

[Brandon Long via mailop]

On Fri, May 26, 2023 at 9:47 AM Scott Mutter via mailop 
wrote:

> It just seems that if people would read the documentation for SPF and
> specify exactly what IP addresses are suppose to be sending email from your
> domain name (I mean... if you own that domain name, shouldn't you know what
> IP addresses are going to be sending legitimate mail from that domain?)
> then the only all operator that should be used is -all.
>
> But because nobody could seem to grasp this idea another record had to be
> created to act as oversight for SPF and DMARC was born.
>
> I fully expect that eventually another oversight record will be created to
> oversee DMARC.
>
> And we wonder why email is in the disarray that it is.
>

It is often useful to understand something before being dismissive of it.

When forwarding mail, there are two options: rewrite the envelope sender or
not.  There are a variety of pros and cons to both of them, and cases where
one or the other is more prominent.  Not rewriting has been the dominant
form of 1:1 forwarding such as aliases and address migration, and enforcing
SPF -all would break that use case.

There were aborted attempts like SRS to fill the gap, but there are
challenges especially with the general desire for such forwarding to be
stateless.

DKIM was the solution, auth that can survive being forwarded as long as the
message isn't modified in transit... but it turns out, messages get
modified in transit sometimes without actually changing the "contents" of
the message in a user
visible way.  Whether that's because DKIM is based on the raw message and
is not content aware, maybe that's part of it.  Also, the bar is higher for
implementing DKIM, and key rotation is always a fun time.

Unlike SPF, DKIM was only authentication, not policy.  The policy portion
was attempted via ADSP, but it suffered from the point that few enough
people implemented DKIM and how to handle the cases where the message was
modified.

DMARC attempts to put the policy of SPF and ADSP together in a simpler
package.  It also solves another fundamental challenge that you think is so
easy, which is reporting so domains have any chance of knowing
what/where/how their domain is being used.
There are entire companies that exist to help domain owners figure out how
they legitimately use their own domain for email.  Look at the SPF include:
list for many modern enterprises to see even a fraction of what that can
mean.

Is DMARC the best thing ever, no.  Are there still issues with it?  Yes.

ARC was the attempt to fill the forwarding gap once and for all... but
fundamental to its design is that it's only providing enough information to
validate the forwarding path.  It doesn't give you a nice warm and fuzzy
yes/no decision.
There have been arguments over whether we need a DMARC++ "no I really mean
it" to not let ARC override DMARC, but the real answer to all of these
things is that the receiver makes the choice.  All we can do is provide as
much useful information
to the receiver as possible so that they can make the best choice they can.

Brightline good/bad decisions are great when you can make them, and the
line on that strictness has been moving over time, but email delivery is
not generally a straight deliver/don't decision.  Even if you think the
answer is a tri-state, the real answer is how do you handle the other
messages like it.  How do you figure out whether you made the right
decision.  How do you make your system adapt over time to changes in the
mail stream.

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

Re: [mailop] Microsoft Office365 not rejecting emails when instructed so by SPF recored?

[Scott Mutter via mailop]

It just seems that if people would read the documentation for SPF and
specify exactly what IP addresses are suppose to be sending email from your
domain name (I mean... if you own that domain name, shouldn't you know what
IP addresses are going to be sending legitimate mail from that domain?)
then the only all operator that should be used is -all.

But because nobody could seem to grasp this idea another record had to be
created to act as oversight for SPF and DMARC was born.

I fully expect that eventually another oversight record will be created to
oversee DMARC.

And we wonder why email is in the disarray that it is.

On Thu, May 25, 2023 at 10:38 PM Neil Jenkins via mailop 
wrote:

> On Fri, 26 May 2023, at 11:10, Scott Mutter via mailop wrote:
>
> So basically SPF is worthless.
>
>
> It's not worthless at all. It's a valuable signal to assign reputation as
> part of an overall filtering solution, and useful as part of DMARC. It's
> just the -all/?all etc. bit on the end that proved worthless.
>
> Cheers,
> Neil.
> ___
> 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] Microsoft Office365 not rejecting emails when instructed so by SPF recored?

[Jaroslaw Rafa via mailop]

Dnia 25.05.2023 o godz. 20:10:02 Scott Mutter via mailop pisze:
> So basically SPF is worthless.  You can define all the IPs that legitimate
> mail for the domain should be coming from and exclude everything else with
> a -all and mail servers are just supposed to ignore that and look for a
> DMARC record?

Interpretation of SPF check results is and always was a decision of the
recipient. The SPF RFC (RFC 7208) says clearly: "Disposition of SPF fail
messages is a matter of local policy."

You can use SPF check results to influence spam score of the message, and it
is usually used this way.
-- 
Regards,
   Jaroslaw Rafa
   r...@rafa.eu.org
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] why some ISP domains have no spf?

[황병희]

Ken Peng via mailop  writes:

> Hello,
>
> Why some huge ISPs do not even have SPF for their sending domains?
> such as att.net and t-online.de.
> I know they may let their users to send email from home DSL via (no-auth)
> relay servers, but since the IPs (no matter relay server or home IP) are
> assigned by them, it's not hard a job for them to have SPF configured.
> for example, t-online's another domain: magenta.de, does have SPF setup.
>
> Thanks.

Probably they do send mail just fine without spf, i guess.


Sincerely, Byung-Hee

-- 
^고맙습니다 _布德天下_ 감사합니다_^))//
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop