>>> that we want to use ToASCII while no current (i.e. not obsolete)
>>> document contains a definition of it. I seem to recall one of the
>>> other co-authors looking into it and finding this was acceptable,
>>> but I don't recall. Dave, can you comment?
>>
>> It would be highly unusual to use s
On 10/21/2010 9:31 PM, SM wrote:
>> I forget; does the email architecture document talk about the
>> difference between a DNS domain and an ADMD?
...
> A proper comparison of the two requirea more than one sentence. I'll
> keep it short; ADMD is about administrative authority whereas a DNS
> dom
I've gone through 4871bis-02 again to look for sections that don't deal
with correctness, robustness, or interoperability and have some suggested
changes. I also noticed a few editing nits on the way. None of this is
intended to be contentious, or to change any of the bits on the wire.
Overall
Hi Murray,
At 13:48 21-10-10, Murray S. Kucherawy wrote:
>That sounds right to me.
It does not sound right to me.
>I forget; does the email architecture document talk about the
>difference between a DNS domain and an ADMD? This was an issue
>during the IESG evaluation of Authentication-Results
RFC 3490 is obsolete, replaced by 5890 and 5891. When they rewrote it
they made the language descriptive rather than prescriptive, and an
A-label is the new name for what was the output of ToASCII.
My understanding is that they actually changed the behavior of the
'subroutine'. Nothing in the
On 10/21/2010 1:48 PM, Murray S. Kucherawy wrote:
>> draft-ietf-dkim-rfc4871bis-02 obsoletes RFC 4871. RFC 5672 updates RFC
>> 4871. Why is the "RFC 4871 DomainKeys Identified Mail (DKIM) Signatures --
>> Update" document not being obsoleted by this document?
>
> That sounds right to me.
+1
> I suggest the two places that refer to IDNS say
>
>Internationalized domain names MUST berepresented as A-labels as
>described in [RFC5891].
>
> That's a current standard, and A-labels are what ToASCII was supposed to
> produce.
That's a technical change to the DKIM Signing specificati
>> Is there a reason why this working group requires that a document
>> with an intended status of "Draft Standard" should have a normative
>> reference to a RFC that has been obsoleted?
>
> I can't remember the disposition of this, but I think the problem is that we
> want to use ToASCII while no
> -Original Message-
> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
> On Behalf Of SM
> Sent: Tuesday, October 19, 2010 2:19 PM
> To: ietf-dkim@mipassoc.org
> Subject: [ietf-dkim] Comments on draft-ietf-dkim-rfc4871bis-02
>
> Hello,
>
> I commented on draf
>> It's that, in order to get the marking, she can't spoof a trusted person's
>> sender address.
>
> DKIM makes no statement about the validity of a "sender" address.
Nor the validity of anything else other than the d= domain. So I am
having trouble figuring out how come people think we can give
That is a different issue all together. We are talking about a
security threat that fell through the cracks during the RFC 5016
production in this group.
It MUST be corrected - pronto, not later, not in another I-D, not in
another WG. No - in 4871bis.
It is rather tiring to seeing the ration
On 10/19/2010 3:11 AM, Ian Eiloart wrote:
> It's that, in order to get the marking, she can't spoof a trusted person's
> sender address.
DKIM makes no statement about the validity of a "sender" address.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
On Oct 21, 2010, at 11:13 AM, John R. Levine wrote:
>> The verifier MAY treat unsigned header fields with extreme
>> skepticism, including marking them as untrusted or even deleting them
>> before display to the end user.
>
> That's an example of the bad advice that I think we should drop from
>
On Oct 21, 2010, at 11:01 AM, Steve Atkins wrote:
> On Oct 21, 2010, at 9:53 AM, Murray S. Kucherawy wrote:
>>
>>
>> Take a tour through the eleven parts of Section 7 of RFC5451, and then
>> Appendices A and C. They provide all kinds of warnings about
>> misinterpreting the data provided, whi
-1.
This is not a LAYER violation. DKIM is a protocol for RFC
822/2822/5322 data to:
a) verify a message signature, and/or
b) create a message signature.
In order to do either requires INPUT that MUST be valid for the
protocol to be fundamentally correct with its OUTPUT.
Therefore it
> Adding and removing Authentication-Results is probably the most common
> modification. Removing header garbage may also be fairly popular, dunno.
> Why do you think it's bad?
Adding A-R is fine. Messing with the message otherwise is more help than
I want from DKIM.
> At any rate, the parag
On Oct 21, 2010, at 9:53 AM, Murray S. Kucherawy wrote:
>
>
> Take a tour through the eleven parts of Section 7 of RFC5451, and then
> Appendices A and C. They provide all kinds of warnings about misinterpreting
> the data provided, which amounts to pretty firm implementation advice, and
> i
> -Original Message-
> From: John R. Levine [mailto:jo...@iecc.com]
> Sent: Thursday, October 21, 2010 9:07 AM
> To: Murray S. Kucherawy
> Cc: ietf-dkim@mipassoc.org
> Subject: More on layer violations
>
> Having pondered the layer thing some more, it occurs to me that we have
> several de
On 21/Oct/10 17:47, John R. Levine wrote:
>> If Big-Bank had been added after signing, verifiers are already
>> authorized to delete that field from the message, according to the
>> current PS. Isn't that enough?
>
> I don't know any DKIM verifier that modifies the message, and I doubt
> that many
Having pondered the layer thing some more, it occurs to me that we have
several decades of practice with software that validates the format of
mail messages to a greater or lesser extent, with the emphasis on lesser.
Different software depends on different bits of the message to be correct,
whi
If Big-Bank had been added after signing, verifiers are already
authorized to delete that field from the message, according to the
current PS. Isn't that enough?
I don't know any DKIM verifier that modifies the message, and I doubt that
many people would want to use one.
Regards,
John Levin
On Oct 16, 2010, at 9:36 AM, Alessandro Vesely wrote:
> *scope*
> Apparently, there is consensus that "Discussion lists and broadcast
> lists are not the same thing" [WV]. Section 3.2 exemplifies
> newsletters and bulk marketing mail as "authoring" MLM modes. In
> facts, most of the advice co
On 20/Oct/10 19:48, Douglas Otis wrote:
> On 10/20/10 7:27 AM, Alessandro Vesely wrote:
>> For example, the initial paragraph of section 5.4 could be
>> modified so as to read:
>>
>> The From header field MUST be signed; that is, it MUST be included
>> at least once in the "h=" tag of the resul
On Wed, 20 Oct 2010 18:32:44 +0100, John R. Levine wrote:
>> A reputation service can only say that a domain is
>>BAD
>>GOOD
>> or NO EVIDENCE AVAILABLE EITHER WAY.
>>
>> I think the last case has to be treated pretty much like GOOD, otherwise
>> newcomers to the internet will never even
On Wed, 20 Oct 2010 15:27:16 +0100, Alessandro Vesely
wrote:
> On 20/Oct/10 13:23, Charles Lindsey wrote:
>> The scam I have described involves the use, by the phisher, of a
>> DKIM-signed (by himself) email with two From: headers, which is intended
>> to fool verifiers into not spotting that
--On 20 October 2010 15:42:32 -0700 Douglas Otis
wrote:
>> But, hey, I'm on your side here. I think we should put a warning in
>> the RFC so that vendors are informed that they need to be sure
>> they're highlighting the correct header.
>
> Why? There would not be a problem when DKIM veri
26 matches
Mail list logo
