Michael Thomas wrote:
Jim Fenton wrote:
Michael Thomas wrote:
Frank Ellermann wrote:
Jim Fenton wrote:
we could easily add verbiage to SSP stating that domains publishing
SSP records other than "unknown" MUST additionally ensure that they
only sign messages purporting to come from themselves when the
address in the From: header field is valid. That way, we're putting
the additional burden on those who publish SSP records but are not
trying to modify the meaning of RFC 4871 at all.
Good idea, a connection to 4409, 4954, and 5068.
So the implication here is that that sort of domain could never run a
mailing
list that resigns messages? That doesn't seem right to me.
That's precisely one of the motivations for the local-part of the i=
tag. If a message from this list, for example, were signed with
i=ietf-dkim(_at_)mipassoc(_dot_)org, the signing address would not match
jdoe(_at_)mipassoc(_dot_)org, so there's no confusion about whether it's an
originator signature or a mailing list signature.
I'm completely lost, sorry. I guess I have no idea what you mean by
"From:
header field is valid" or "coming from themselves".
It seems that my language wasn't precise enough, so let me take another
shot at it.
It has been noted that when a signing domain "claims responsibility for
the introduction of a message into the mail stream" it is not actually
asserting the validity of any part of the message. This is relevant to
SSP because it has a dependency on whether the Signing Address (i=
address or its default) matches the address in the From: header field.
I propose to solve that problem by adding language similar to the
following to the SSP draft:
Domains publishing SSP records indicating practices other than
"unknown" MUST ensure the validity [correctness] of the address in the
From: header field for messages to which they apply an Originator
Signature.
In other words, before applying an Originator Signature, make sure the
message isn't spoofed.
-Jim
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html