On 1/17/2019 8:53 AM, John Levine wrote:
In article<43ae9a84-75e3-1292-d3f4-68f3a7445...@spamtrap.tnetconsulting.net
you write:
However I still feel like/requiring/ exact case is contrary to the idea
of "Be liberal in what you accept and conservative in what you send.".
Yup. See
https://dat
In article <43ae9a84-75e3-1292-d3f4-68f3a7445...@spamtrap.tnetconsulting.net>
you write:
>However I still feel like /requiring/ exact case is contrary to the idea
>of "Be liberal in what you accept and conservative in what you send.".
Yup. See
https://datatracker.ietf.org/doc/html/draft-iab-pr
On 01/16/2019 11:34 AM, Grant Taylor wrote:
However I feel like rejecting things because of additional white space
(in front of v=...) or the wrong case is being a little bit pedantic.
Rather, I think that if removing a spurious / leading space or folding
case causes the DMARC record to be val
> I believe in the situation where standard is absolutely clear like this,
> any implementer must strictly follow the standard. Otherwise, it can
> lead to unpredictable behavior and security issues.
Sorry, I meant to mention this in my previous response. It's one thing
when there's wiggle-room
On 1/16/2019 11:18 AM, John Levine wrote:
> Remember, that if your software rewrites an invalid record into a
> correct one, you are trying to read the mind of the person who wrote
> the misformed record.
To emphasize a point you made earlier: There are many, small
adjustments that a receiver
+1
I concur with Mike and Andrew. There's no no reason to ignore this element
of the standard because there's no real barrier (other than lack of
attention to the spec) preventing implementors from doing this correctly.
And all we'd be doing is pushing the burden of handling ambiguity to the
rece
+1
Too many times we (collectively) have avoided the short term pain because
it is pain, but we have set ourselves up for greater pain at a later point.
Part of the problem with ignoring the requirements of a standard is that
while interoperability works in most cases, it sets up failure in corner
Hi,
On Wed, Jan 16, 2019 at 11:34:56AM -0700, Grant Taylor wrote:
>
> However I feel like rejecting things because of additional white space (in
> front of v=...) or the wrong case is being a little bit pedantic.
I want to point out, because it's making me extremely itchy, that the
DNS itself di
I believe in the situation where standard is absolutely clear like this,
any implementer must strictly follow the standard. Otherwise, it can
lead to unpredictable behavior and security issues.
Example: there are absolutely legal situations where non-trusted or less
privileged side can partially
On 1/16/2019 11:18 AM, John Levine wrote:
Remember, that if your software rewrites an invalid record into a
correct one, you are trying to read the mind of the person who wrote
the misformed record.
To emphasize a point you made earlier: There are many, small
adjustments that a receiver migh
In article <7c8aa4a8-7d75-db07-7e97-82d9b0ffb...@gmail.com> you write:
>If more flexibility is viewed by the community as desirable, then the
>community should enhance the specification to allow it. This improves
>robustness while retaining a firm, clear and precise standard.
Do keep in mind th
However I feel like rejecting things because of additional white space
(in front of v=...) or the wrong case is being a little bit pedantic.
Rather, I think that if removing a spurious / leading space or folding
case causes the DMARC record to be valid, it behooves us to tolerate
such minor
On 01/16/2019 10:26 AM, John R Levine wrote:
Maybe, but that's not what standards are about. The point of a standard
is to say here's what you do if you want to interoperate. I have never
found it productive to speculate about what you might or might not want
to do when you run into people wh
Is there really a benefit in filtering out people/organizations that are
not fastidious in the use of whitespace and character case?
Maybe, but that's not what standards are about. The point of a standard
is to say here's what you do if you want to interoperate. I have never
found it product
Is there really a benefit in filtering out people/organizations that are
not fastidious in the use of whitespace and character case?
Seems overly nitpicky and something to reconsider as we look forward
forward a standards track for DMARC.
On Wed, Jan 16, 2019, 07:52 John R Levine > The ABNF rule
The ABNF rule I included, and the one that cites it (dmarc-record) do not
show any white space permitted before the 'v', so no it's not legal.
Ah, now that I look at it again, I see that the dmarc-record rule is the
one that matters here, since it allows WSP after the version but not
before.
On 1/16/2019 7:30 AM, John R Levine wrote:
The formal specification is quite clear on both of your questions:
Section 6.4:
dmarc-version = "v" *WSP "=" *WSP %x44 %x4d %x41 %x52 %x43 %x31
which means that the white space is required to be allowed and the
value in this tag-value is case
The formal specification is quite clear on both of your questions:
Section 6.4:
dmarc-version = "v" *WSP "=" *WSP %x44 %x4d %x41 %x52 %x43 %x31
which means that the white space is required to be allowed and the value in
this tag-value is case sensitive.
Thanks, but the white space in
On 1/15/2019 4:58 PM, John Levine wrote:
I am staring at RFC 7489, and at a bunch of purported DMARC records
(see previous message.)
The RFC says that all records must start with "v=DMARC1". Is it OK
if they start with "v=dmarc1"? It says that record is a DKIM tag-value
list, and the DKIM ABBF
I am staring at RFC 7489, and at a bunch of purported DMARC records
(see previous message.)
The RFC says that all records must start with "v=DMARC1". Is it OK
if they start with "v=dmarc1"? It says that record is a DKIM tag-value
list, and the DKIM ABBF defines all the characters with hex escape
20 matches
Mail list logo
