Re: [ietf-dkim] Re: from'less 2822 messages

Frank Ellermann wrote:
> Hector Santos wrote:
>
> > +1.
> A few days ago you said that more than one From address 
> is irrelevant, and that "resending" old unsigned mails 
> is as irrelevant as the whole concept of "resend", for
> your stated POV a "+1" to Ned's concerns is rather odd.
I said no such thing.

As a 25+ year veteran of the telecommunications, online hosting and 
electronic mail system and product design and commercial product 
manufacturer, it is ridiculous to suggest that none of this will work 
because there is the obvious potential of bad people sending 
non-compliant data.
From the get-go, I thought the idea of trying to address all possible 
blatant malicious abuse of mail is ridiculous - see my "Price of Rice" 
message.   And your particular input in regards to resending mail as 
"me" is no different.  As long as you don't alter the originality, I 
don't see that as a problem.  If you intend to break it, then you have 
to be able to taken into account the "new considerations."  In my book, 
this would be a "Feature" to stop you from resending my mail in an 
altered state.
Now, I also said in more ways than one, provided we have a x822 
compliant message, there is no flaw in the concept of SSP looking up 
multiple From: co-author domains. I even provided some technical 
automating ideas to work with it.  I see that as a "no-brainer" and I 
think most programmers/developers will agree with me.
But I also indicated this is typically an issue or question of overhead 
and redundancy and we all know this can be controlled in the same way 
other technology or protocols has placed practical limitations in 
general in many aspects of the protocol; line limits, spaces or no 
spaces, etc, including DNS clients with its limits and more SPF with its 
recursive limits which is the closest facsimile for this concern.
All and all, this all is really about implementation and completely 
unrelated to the basic fundamental SSP protocol.  But I am one that 
believes that implementation guidelines and insights should be part of 
the functional and technical specification whichever you wish to call an 
RFC.
So sure, I am happy we have respective people like Ned finally around to 
provide input which I sincerely hope helps bring back some practical 
sanity in all this.

--
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html