On Thu, 2006-11-23 at 14:00 -0500, Hector Santos wrote:
> Charles Lindsey wrote:
> 
>  > If writers of verifiers find it useful to use knowledge of the
>  > envelope addresses, then they will do so, whatever we say. Those
>  > fighting spam cannot do so with one hand tied behind their backs.
> 
> So you have a generalize rule everyone should follow?
> 
> That is what we need to stop trying to impose.  What is consistent in
> all systems is a 2822.FROM and that is what DKIM/SSP is based on.

This generalization is incorrect.  Other headers can be accommodated:

http://tools.ietf.org/wg/dkim/draft-otis-dkim-dosp-02.txt

DKIM will never be effective at blocking spam.  Spoofing can only be
stopped by comparisons with lists established by recipients, such as
utilizing their address-book.  A policy to establish expectations of a
signature is unnecessary and is unlikely to curtail a meaningful amount
of abuse.  Once EAI becomes commonly used, a strategy based upon From
header signature compliance falls apart.

Associations with the MAILFROM and the SMTP client utilizing the DKIM
signature can protect against abusive replays when white-listing, and
ensure DSNs.  Associations offer far more protection from abuse than
policy statements such as:

 "All From email-addresses are signed and this invites altered messages
  to be dropped or rejected"

It is clear this type of policy breaks mailing-lists and prevents
modifications needed for EAI.  Even when the EAI alternations are made
prior to signing, there is now the issue that two different
email-addresses that may be present within the new header (one suitable
for UTF-8 and one for ASCII).

Other aspects related to an association scheme can provide these
additional features:

1) Allow email-address domain owners to independently establish
   relationships with email-provider's signing domain without a need to
   relinquish use of their private keys.  Freedom of choice at no cost.

2) Allow email-address domain owners to independently indicate
   assurances of their email-address's validity.

3) Ensure the DKIM signing domain relates the entity transmitting the
   message.  The transmitting entity may have their IP address
   held accountable for spam. Ensuring feedback is sent to the
   transmitting entity offers better and more effective protections.

4) A means to associate the signing domain with the SMTP client is
   essential for protecting the transmitting entity from possible replay
   abuse perpetrated by their customers.  The lack of an SMTP client
   association would disable white-listing.

-Doug

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

Reply via email to