On 30 Mar 2024, at 17:22, John R. Levine wrote:
Entities other than domains: Public suffixes aren’t (necessarily) domains,
>>>
>>> Of course they're domains. What else could they be? The things that are
>>> out of scope are IP addresses, ASNs, magic tokens in the messages, stuff
>>>
On March 31, 2024 3:20:41 PM UTC, Jim Fenton wrote:
>
>
>On 30 Mar 2024, at 17:22, John R. Levine wrote:
>
> Entities other than domains: Public suffixes aren’t (necessarily) domains,
Of course they're domains. What else could they be? The things that are
out of scope are
On 3/31/2024 11:32 AM, Alessandro Vesely wrote:
On Sun 31/Mar/2024 14:22:04 +0200 Douglas Foster wrote:
On SPF, our document should say simply,
" a DMARC-compliant evaluator MUST NOT reject a message, based on SPF
result, prior to receiving the Data section and checking for aligned
and
On March 30, 2024 11:27:42 PM UTC, "Murray S. Kucherawy"
wrote:
>On only the charter point:
>
>On Sat, Mar 30, 2024 at 2:27 PM Jim Fenton wrote:
>
>>
>> >> ??? Not Found
>> >> -
>> >>
>> >> I expected to find some text at least recommending a rewriting strategy
>> for From
On Sun 31/Mar/2024 18:43:53 +0200 Scott Kitterman wrote:
On March 31, 2024 3:20:41 PM UTC, Jim Fenton wrote:
On 30 Mar 2024, at 17:22, John R. Levine wrote:
Mine wasn’t a good example. There are a few public suffixes that have more than
5 labels. Presumably that means there are registered
Our advice is not to publish a DMARC policy if you want to use mailing lists.
We have a lot of experience with message rewriting and I think we have all
found that the options range from pretty bad to really bad, so there's nothing
to recommend.
“Our advice” seems not to be followed by many
On March 31, 2024 5:32:13 PM UTC, "John R. Levine" wrote:
I’m probably being pedantic here: is “gov” a domain?
>>> Yup, it's a domain.
>> I stand corrected on that.
>
>Anything that meets the DNS spec is a domain namen, e.g., argle.bargle.parp is
>a domain name. If and how particular
It appears that Mark Alley said:
>> People who publish -all know what they do.
>
>I posit that there is a non-insignificant amount of domain owners that
>don't know what the consequences of -all are other than that they've
>been instructed to use "-all" by a guide online, ...
I'm with you.
On Sat 30/Mar/2024 21:05:17 +0100 Seth Blank wrote:
This is a real operational problem, so I wanted to expand guidance. The note
about best practice may or may not be appropriate here, but I think it works.
There are multiple M3AAWG documents which cover this use case, and we can also
link
What do you mean “stop authenticating?” — a soft fail is still a fail, not
a lack of auth, and this has been published best practice for a decade
S -mobile
Seth Blank | Chief Technology Officer
Email: s...@valimail.com
This email and all data transmitted with it contains confidential and/or
Count| Bytes | Who
++---
33 ( 100%) | 260931 ( 100%) | Total
11 (33.3%) | 59746 (22.9%) | Alessandro Vesely
7 (21.2%) | 37255 (14.3%) | John Levine
4 (12.1%) | 51406 (19.7%) | Jim Fenton
4 (12.1%) | 26151 (10.0%) | Matthäus Wander
On SPF, our document should say simply,
" a DMARC-compliant evaluator MUST NOT reject a message, based on SPF
result, prior to receiving the Data section and checking for aligned and
verifiable signatures."
Of course, evaluators may still reject early base on known-bad server or
known-bad Mail
On Sun, Mar 31, 2024 at 2:00 PM John Levine wrote:
> It appears that Mark Alley said:
> >> People who publish -all know what they do.
> >
> >I posit that there is a non-insignificant amount of domain owners that
> >don't know what the consequences of -all are other than that they've
> >been
On Sun, Mar 31, 2024 at 9:32 AM Alessandro Vesely wrote:
> On Sun 31/Mar/2024 14:22:04 +0200 Douglas Foster wrote:
> > On SPF, our document should say simply,
> > " a DMARC-compliant evaluator MUST NOT reject a message, based on SPF
> result,
> > prior to receiving the Data section and checking
On Sun, Mar 31, 2024 at 3:28 PM Richard Clayton
wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> In message 7...@mail.gmail.com>, Seth Blank
> writes
>
> >Some Mail Receiver architectures implement SPF in advance of any
> >DMARC operations. This means that an SPF hard fail
I’m saying, as an individual, that there was a thread where we discussed a
new N for the tree walk. There was appetite, but no new N was settled on.
Given that prior appetite but no conclusion, I believe as part of WGLC we
should choose that N. I proposed what I think would work. John Levine
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
In message , Seth Blank
writes
>Some Mail Receiver architectures implement SPF in advance of any
>DMARC operations. This means that an SPF hard fail ("-") prefix on
>a sender's SPF mechanism, such as "-all", could cause that
>
On Sun, Mar 31, 2024 at 1:40 PM Scott Kitterman
wrote:
>
>
> On March 31, 2024 5:32:13 PM UTC, "John R. Levine" wrote:
> I’m probably being pedantic here: is “gov” a domain?
> >>> Yup, it's a domain.
> >> I stand corrected on that.
> >
> >Anything that meets the DNS spec is a domain namen,
On March 31, 2024 7:49:08 PM UTC, Seth Blank
wrote:
>On Sun, Mar 31, 2024 at 1:40 PM Scott Kitterman
>wrote:
>
>>
>>
>> On March 31, 2024 5:32:13 PM UTC, "John R. Levine" wrote:
>> I’m probably being pedantic here: is “gov” a domain?
>> >>> Yup, it's a domain.
>> >> I stand corrected on
On Sun, Mar 31, 2024 at 5:22 AM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> On SPF, our document should say simply,
> " a DMARC-compliant evaluator MUST NOT reject a message, based on SPF
> result, prior to receiving the Data section and checking for aligned and
> verifiable
It is a very common issue that companies want DMARC, but their security
teams believe an SPF hard fail is more secure, and then all sorts of actual
operational issues slam in. It ends up being lots of work to convince those
security teams otherwise.
I think it is desirable to state that this
On Sun 31/Mar/2024 14:22:04 +0200 Douglas Foster wrote:
On SPF, our document should say simply,
" a DMARC-compliant evaluator MUST NOT reject a message, based on SPF result,
prior to receiving the Data section and checking for aligned and verifiable
signatures."
Nonsense. Rejecting at RCPT
On Sun 31/Mar/2024 18:50:16 +0200 Mark Alley wrote:
On 3/31/2024 11:32 AM, Alessandro Vesely wrote:
People who publish -all know what they do.
I posit that there is a non-insignificant amount of domain owners that don't
know what the consequences of -all are other than that they've been
I’m probably being pedantic here: is “gov” a domain?
Yup, it's a domain.
I stand corrected on that.
Anything that meets the DNS spec is a domain namen, e.g.,
argle.bargle.parp is a domain name. If and how particular names might be
resolved is a topic to which the IETF and ICANN have given
There are three items in the document that have consensus, which I believe
are wrong. I am in the rough on these, and not looking to relitigate them.
I am hoping to provide text that clarifies concerns in a manner that leads
consumers of the document to make better informed implementations, and I
In addition to the editorial review I have provided, I have significant
concerns regarding the standardization of DMARC-bis. I do not expect
that the working group rough consensus will necessarily agree with these
concerns, but I want to state them for the working group and will
probably
26 matches
Mail list logo
