On Tue 19/Mar/2024 12:33:07 +0100 Scott Kitterman wrote:
On Tuesday, March 19, 2024 5:23:52 AM EDT Alessandro Vesely wrote:
On Mon 18/Mar/2024 21:37:02 +0100 Scott Kitterman wrote:
> On March 18, 2024 6:40:54 PM UTC, Alessandro Vesely wrote:
On Mon 18/Mar/2024 09:14:26 +0100 Dotzero wrote:
On Tuesday, March 19, 2024 5:23:52 AM EDT Alessandro Vesely wrote:
> On Mon 18/Mar/2024 21:37:02 +0100 Scott Kitterman wrote:
> > On March 18, 2024 6:40:54 PM UTC, Alessandro Vesely
wrote:
> >>On Mon 18/Mar/2024 09:14:26 +0100 Dotzero wrote:
> >>> On Mon, Mar 18, 2024 at 2:38 AM John R Levine
On Mon 18/Mar/2024 21:37:02 +0100 Scott Kitterman wrote:
On March 18, 2024 6:40:54 PM UTC, Alessandro Vesely wrote:
On Mon 18/Mar/2024 09:14:26 +0100 Dotzero wrote:
On Mon, Mar 18, 2024 at 2:38 AM John R Levine wrote:
On Sun, 17 Mar 2024, Dotzero wrote:
Whenever mail is sent, there is a
On March 18, 2024 6:53:29 PM UTC, John R Levine wrote:
>On Mon, 18 Mar 2024, Alessandro Vesely wrote:
>> The text should be terser and clearer, possibly with an example.
>
>I would be happy to remove the whole thing, since it's only distantly related
>to defining or implementing DMARC.
I
On March 18, 2024 6:40:54 PM UTC, Alessandro Vesely wrote:
>On Mon 18/Mar/2024 09:14:26 +0100 Dotzero wrote:
>> On Mon, Mar 18, 2024 at 2:38 AM John R Levine wrote:
>>> On Sun, 17 Mar 2024, Dotzero wrote:
> Whenever mail is sent, there is a risk that an overly permissive source
> may
Now with Mike's tweak:
Add this to 11.1 Authentication Methods
Both of the email authentication methods that underlie DMARC provide some
assurance that an email was transmitted by an MTA which is authorized to
do so. SPF policies map domain names to sets of authorized MTAs [ref to
RFC 7208,
On Mon, 18 Mar 2024, Alessandro Vesely wrote:
The text should be terser and clearer, possibly with an example.
I would be happy to remove the whole thing, since it's only distantly
related to defining or implementing DMARC.
Regards,
John Levine, jo...@taugh.com, Taughannock Networks,
On Mon 18/Mar/2024 09:14:26 +0100 Dotzero wrote:
On Mon, Mar 18, 2024 at 2:38 AM John R Levine wrote:
On Sun, 17 Mar 2024, Dotzero wrote:
Whenever mail is sent, there is a risk that an overly permissive source
may send mail which will receive a DMARC pass result that was not, in
fact,
On Mon, Mar 18, 2024 at 2:38 AM John R Levine wrote:
> On Sun, 17 Mar 2024, Dotzero wrote:
> >> Whenever mail is sent, there is a risk that an overly permissive source
> >> may send mail which will receive a DMARC pass result that was not, in
> >> fact, authorized by the Domain Owner. These
Murray S. Kucherawy skrev den 2024-03-18 04:15:
It is not a false positive in that the technology did exactly what it
was supposed to do; i.e., this is not a bug.
We should just be clear about this.
how to make dmarc fully aligned when spf +all is allowed :(
it renders no go
rfc is already
On Sun, 17 Mar 2024, Dotzero wrote:
Whenever mail is sent, there is a risk that an overly permissive source
may send mail which will receive a DMARC pass result that was not, in
fact, authorized by the Domain Owner. These false positives may lead
to issues when systems interpret DMARC pass
On March 18, 2024 3:15:42 AM UTC, "Murray S. Kucherawy"
wrote:
>On Mon, Mar 18, 2024 at 1:08 PM Dotzero wrote:
>
>>
>> Add this to 11.1 Authentication Methods
>>>
>>>
>>> Both of the email authentication methods that underlie DMARC provide
>>> some assurance that an email was transmitted by
On March 18, 2024 1:36:29 AM UTC, John Levine wrote:
>Tightened up a little, reworded in view of the fact that your own
>mail provider (M*r*s*ft) may let people spoof you through shared IP ranges.
>
>
>>11.X External Mail Sender Cross-Domain Forgery
>
>Add this to 11.1 Authentication Methods
On Mon, Mar 18, 2024 at 1:08 PM Dotzero wrote:
>
> Add this to 11.1 Authentication Methods
>>
>>
>> Both of the email authentication methods that underlie DMARC provide
>> some assurance that an email was transmitted by an MTA which is
>> authorized to do so. SPF policies map domain names to
On Sun, Mar 17, 2024 at 9:36 PM John Levine wrote:
> Tightened up a little, reworded in view of the fact that your own
> mail provider (M*r*s*ft) may let people spoof you through shared IP ranges.
>
>
> >11.X External Mail Sender Cross-Domain Forgery
>
> Add this to 11.1 Authentication Methods
Tightened up a little, reworded in view of the fact that your own
mail provider (M*r*s*ft) may let people spoof you through shared IP ranges.
>11.X External Mail Sender Cross-Domain Forgery
Add this to 11.1 Authentication Methods
Both of the email authentication methods that underlie DMARC
It appears that Scott Kitterman said:
>1. Bad mail gets DMARC pass and so DMARC policy is not applied (avoid
>consequences of DMARC fail).
>
>2. Bad mail gets DMARC pass and something else (e.g. BIMI) does a wrong thing
>(gets benefits of DMARC pass).
I agree these are the two main points.
But if we have no advice on how to detect a false Pass, how is this
useful? Are we helping evaluators or just giving ourselves cover that
"your disaster is not our fault because we warned you"?
On Sun, Mar 17, 2024, 10:59 AM Scott Kitterman wrote:
>
>
> On March 17, 2024 11:11:04 AM UTC,
On March 17, 2024 11:11:04 AM UTC, Alessandro Vesely wrote:
>On Sat 16/Mar/2024 20:01:22 +0100 Scott Kitterman wrote:
>> On Thursday, March 14, 2024 12:24:50 PM EDT Scott Kitterman wrote:
>>> On Thursday, March 14, 2024 11:44:22 AM EDT Todd Herr wrote:
Issue 135 is open for the
On Sat 16/Mar/2024 20:01:22 +0100 Scott Kitterman wrote:
On Thursday, March 14, 2024 12:24:50 PM EDT Scott Kitterman wrote:
On Thursday, March 14, 2024 11:44:22 AM EDT Todd Herr wrote:
Issue 135 is open for the subject topic. Please add your thoughts to this
thread and/or to the issue in
On Thursday, March 14, 2024 12:24:50 PM EDT Scott Kitterman wrote:
> On Thursday, March 14, 2024 11:44:22 AM EDT Todd Herr wrote:
> > Colleagues,
> >
> > Issue 135 is open for the subject topic. Please add your thoughts to this
> > thread and/or to the issue in Github.
> >
> > Thank you.
>
>
On Thursday, March 14, 2024 11:44:22 AM EDT Todd Herr wrote:
> Colleagues,
>
> Issue 135 is open for the subject topic. Please add your thoughts to this
> thread and/or to the issue in Github.
>
> Thank you.
I'd suggest we discuss where to say it first. I think the right place is
security
On Thu 14/Mar/2024 16:44:22 +0100 Todd Herr wrote:
Issue 135 is open for the subject topic. Please add your thoughts to this
thread and/or to the issue in Github.
I proposed an alternative text for section 5, Policy[*]. I repeat it here with
an added sentence:
OLD
A Domain Owner or
Colleagues,
Issue 135 is open for the subject topic. Please add your thoughts to this
thread and/or to the issue in Github.
Thank you.
--
Todd Herr | Technical Director, Standards & Ecosystem
Email: todd.h...@valimail.com
Phone: 703-220-4153
This email and all data transmitted with it
24 matches
Mail list logo
