No, see RFC 2821 or 5321 sec 3.3. The reverse-path is what's between
the brackets, which means it's a mailbox or it's empty.
Ok, I guess I didn't expect to have to go through a layer of english
while assembling a grammar from different sources, given that there was
an ABNF rule with a matching
> No, see RFC 2821 or 5321 sec 3.3. The reverse-path is what's between
> the brackets, which means it's a mailbox or it's empty.
Ok, I guess I didn't expect to have to go through a layer of english
while assembling a grammar from different sources, given that there was
an ABNF rule with a
RFC5321.MailFrom is the address in the SMTP "Mail From" command
So is RFC5321.MailFrom the Reverse-Path from RFC5321, or only the
Mailbox part of a Reverse-Path? I would expect it to be the full
Reverse-path, because
RFCs 2821 and 5321 say:
Historically, the was permitted to contain more
> RFC8601 sec 2.7.2 refers to RFC 7208 for "mailfrom". RFC 7208 sec 1.1.3
> says that the MAIL FROM, which I whink we can assume is the same thing,
> is the RFC5321.MailFrom from RFC 5598. RFC 5598 says that's a mailbox,
> not a domain name.
Those definitions are too confusing for me. RFC5598
In article you write:
> [SPF] on the other hand
>has an A-R example that is domain-name only, so I assumed that
>smtp.mailfrom in spf context was more loosely defined via RFC7001's
>pvalue (that is, with the optional local-part@).
I'm pretty sure the example is wrong, and was copied verbatim
Hi,
> resinfo = [CFWS] ";" methodspec [ CFWS reasonspec ]
> [ CFWS 1*propspec ]
>
> I think both the erratum and RFC 8601 are wrong, and it should say:
>
> resinfo = [CFWS] ";" methodspec [ CFWS reasonspec ]
> 1*( CFWS propspec )
>
> Every implementation I know puts
In article you write:
>>> Every implementation I know puts space between multiple propspec's
>>> which the current syntax wouldn't allow
>> my understanding was that RFCs decide whether an implementation is
>> incorrect or in the case of a series, not up-to-date. If the authors
>> decided to
>> Every implementation I know puts space between multiple propspec's
>> which the current syntax wouldn't allow
> my understanding was that RFCs decide whether an implementation is
> incorrect or in the case of a series, not up-to-date. If the authors
> decided to update the RFC instead, then I'd
In article you write:
>Hello DMARC working group,
>
>I am going through the changes between RFC7601 and RFC8601 and try to
>understand the implication of the change introduced by erratum 5435.
>The new resinfo definition uses 1*propspec, that is, by my understanding
>of [1] and [2], potentially
