On 8 Feb 2018, at 10:23, Dave Crocker wrote:
On 2/8/2018 10:05 AM, Pete Resnick wrote:
So, no error in 5322. As for the erratum below, not having ABNF for
the header field does seem like a miss, though I'm not sure it should
be marked as more than "Hold for document update".
itive, specify the characters
individually.
RFC 7405 is also useful along these lines.
So, no error in 5322. As for the erratum below, not having ABNF for the
header field does seem like a miss, though I'm not sure it should be
marked as more than "Hold for document update".
fectly clear in the document.
In any event, neither of Charles suggested additions captured what I
have written above. I believe the current text does.
pr
--
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102
ion in the document about
how broken it is for a recipient to do such a thing, and put *that* into
the security consideration, but I don't think it's necessary. The above
can only obfuscate that very important point, making it out as if it's
something in the DKIM signing/verifyin
3.8 is a red herring. DKIM deals perfectly well with the
obsolete message format, including multiple From fields. I think the 3.8
admonition is overblown.
> In my opinion, there needs to be some REQUIRED action in the verifier which
> will result in a PERMFAIL, and which would then catch all at
local policy and is
>> beyond the scope of this document.
>>
>> The two clauses in that sentence seem contradictory. Is there an
>> interoperability requirement that I not treat messages in a particular
>> way, or
syntax, which does
allow things like multiple From: fields on messages. The
implementation of DKIM thus potentially creates a more stringent
layer of expectation regarding the meaning of an identity, while that
additional meaning is either obscured fr
plementations very much depend on the RFC 2119
definitions of these terms and this document had better as well.
pr
--
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102
___
creates
> the silly-state of DKIM wagging the 8bit SMTP tail, which is a wrong
> outcome.
>
I'm not sure what you mean here. What is the "right" outcome?
pr
--
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-447
eans. If there is an
implementation that doesn't downgrade and sends a message without
knowing that the path is end-to-end 8-bit clean, then it is in violation
of the spec. Changing it to MUST doesn't change anything for such an
implementation; it is already in full
Sean
get to collectively make.
3. One can always publish something as BCP now, and if in the future you
find that my experiment was so wildly successful that you wish to have a
document as an AS, you can always re-publish, obsoleting the BCP.
Hope that helps.
pr
--
Pete Resnick<http://www.qualco
r:" field. If DKIM/SSP wants to
require (or REQUIRE) the "Sender:" field, that would be a bad thing.
But I haven't seen anything to that effect in what I've been reading.
I'll go back to lurking now, and the rest of you can go back to your
regularly scheduled love-fest.
pr
--
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
ent that a list should add a Resent-Sender: rather than a
Sender: but it's reasonable to do it either way.
Mailing lists using Resent-* fields gives me the willies. Resent-*
fields were intended for MUAs resending mail. They weren't intended
for mailing lists.
pr
--
Pete Resnick
13 matches
Mail list logo
