On 5/8/11 19:21 , "Murray S. Kucherawy" <msk(_at_)cloudmark(_dot_)com> wrote:
-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Franck Martin
Sent: Friday, May 06, 2011 9:32 PM
To: ietf-dkim(_at_)mipassoc(_dot_)org
Subject: Re: [ietf-dkim] I-D ACTION:draft-ietf-dkim-mailinglists-08.txt
Sorry if I jump in, some comments:
+1 to Barry's comment about this being a week late. :-(
Sorry, but I saw it more as an exercise for me to better understand the
spec and to look into email policies.
4.3 it would be nice to talk about message encoding change like
QP->8bits,
may be in minor or major body changes. It is a minor change for the
human
but major for the machines as many characters got changed.
Which MLMs do this? I've never heard of that.
Well, not necessarily the MLM but it seems sendmail in the process may
change QP to 8bits. I thought it would be worth mentioning.
5.1 "Some mail filtering software incorrectly penalizes a message
containing a DKIM signature that fails verification." You should
remind/add that a message that fails DKIM must be considered like having
no signature at all. Then you can bring ADSP, policy in the picture, and
there ADSP too will not make the difference if a message has no
signature
or a failed signature. I have the feeling that making the point clears
helps in building message policies (out of scope of this document).
I don't think it's necessary to add at this point; we've already stated
that DKIM itself is mandatory reading, plus it seems redundant to say
that after the "incorrectly penalizes" remark.
You mention that a message that fails signature must be considered like no
signature a bit later in the document, so why not here too?
Moreover, ADSP does indeed make a difference if a message has no
signature or a failed signature, so that part seems wrong to me.
noted
And finally, if the point of adding such a remark is to enable policy
discussions, but policies are out of scope, then it seems like adding it
is a bad idea.
"such as a signing and author subdomain {DKIM 12}" -> "such as a signing
and author subdomain {DKIM 12} or a totally different domain"
I'm on the fence on this one. Does anyone else have an opinion?
It is a best practice document so the full realm of possibilities should
be included.
5.2 There are some professional services that allows to look in to
reception at some providers
Do you have some specific text you want to propose here? I couldn't
imagine any based on this comment.
Yes it is hard, because we don't want to endorse any product/service. Let
me try.
"Some MTA senders and receivers can enter in bilateral agreements or via a
third party to receive out of band reports on failed signatures."
5.3 postmaster should inform their users that messages are likely to be
discarded if sent via a MLM.
Is this inbound or outbound? I assume inbound given the title of the
section. But again I couldn't concoct text in my head to match your
remark. Can you propose some?
I thinking outbound. As this document is to give postmasters a quick
start, then it is good to mention if you choose ADSP, there is "no way"
the message can go via a mailing list and survive. I thought it was
possible before reading this RFC that you could tweak a MLM in a manner
that ADSP would not break, but I realize while possible it is absolutely
impractical and as you say a cooperating MLM better drop the message out
front.
What I'm worried is that it does not set a mindset with other email
policies that can be created.
6.8 talk about headers to add to the message but do not talk which
recommended headers should be signed. They are specified in DKIM 5.5 but
would be nice to do a reminder here specific to MLM.
It says to sign the entire message. There was previously text in there
that made specific recommendations about what to sign, like "sign any
fields the MLM added or changed" or "sign the parts for which you want to
take some responsibility", but the text that's there now won in the end.
I had recently the experience with Ironport old version, which had a
tendency to hard sign List- headers even if not present. Recent versions
do not do that, and I think they got confused by the DKIM RFC, but if now
this is fixed...
Speaking of DKIM 5.5, List- headers are recommended to be signed, but
doesn't it creates confusion? My feel is that they should be signed
only
if present in the message, if they are not present DKIM should not
mention
them in h= at all.
The text after the list in the current RFC4871bis Section 5.5 handles
this topic nicely, I believe.
-MSK
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html