On Jan 18, 2006, at 7:51 AM, Frank Ellermann wrote:
Douglas Otis wrote:
The From header may then need to have multiple addresses
introduced, where the first email-address would be that of the
mailing-list.
NAK.
This consideration depends upon:
1) When replay abuse becomes a serious problem, the defensive
reaction of obfuscating signatures by the MDA or mediator also means
not altering the message is not a solution.
2) When an SSP policy associated with the From email-address
increases the rating of a message, publishing closed polices may
become a necessary defense.
Modifying the message is already a common practice by list-servers
and resigning a modified message may not overcome restrictions
imposed by a From email-address policy.
In the dkim-options draft, rather than restricting an email-address,
the goal was to identify unique sources and highlight recognized
correspondents. This included the ability to assert a signing role
such as mediator, as in the case of a list-server. Adding a signing
role avoids difficulties in classifying the nature of the source and
may squelch conflict notifications.
It may also require that the From email-address be moved entirely
into the body of the message and replaced with the email-address
of the mailing-list.
NAK.
This would be a follow-on of the closed policy issue when dealing
with message changes. There has been a suggestion that all From
email-address be checked against a policy to determine the most
restrictive policy. This would then mean adding multiple From email-
addresses would not be a solution for avoiding policy restrictions.
If a message sent to a list-server opted to not include the Subject
header as a means to increase compatibility, then instantly these
messages become a way to send subject line spam. When messages use a
body-length to increase compatibility with list-servers, then again
instantly these messages become a way to send spam. Of course, any
abusive message replay could hurt the reputation of the individual
sending to the list. A defensive posture in reaction to this problem
may be to exclude signatures when sending to a list-server or ask the
list-server to remove or obfuscate incoming signatures. Resigning
and obfuscation of incoming signatures would preserve valuable
information and dramatically reduce potential sources for message
replay abuse.
-Doug
_______________________________________________
ietf-dkim mailing list
http://dkim.org