Re: [ietf-dkim] Re: An overview of cryptographic protocols to preventspa

On Sep 25, 2005, at 11:40 PM, Amir Herzberg wrote:

> John Levine wrote:
>
> > Note on the first page: I'd skip the comment about content  
> > labels.  In
> > the few places they've been tried (Korea, most notably) they've  
> > been a
> > resounding failure, and there's no point in encouraging people to
> > waste time thinking about them.
> Thanks for the feedback. Reference to that experiment (Korea) would  
> be appreciated.
> I agree that labeling seems difficult to deploy. However, I think  
> that when there is a widely accepted label, e.g. ADV in subject  
> line, then sending appropriate content (advertisements) with this  
> label is an acceptable practice. Therefore, I do not regard this as  
> spam. Such well-labeled email can be easily filtered, of course,  
> and most recipients (and maybe mail servers) may do so.  Do you  
> object and if so, why?
Offering a label that a message is an advertisement does _not_  
indicate whether the message was solicited.  Any advertisement,  
labeled or not, representing one of perhaps an inordinate number of  
such messages should _still_ be viewed as spam.  Such messages are  
primarily in the sender's interest, and primarily at the expense of  
the recipient. The test for whether a message is spam should not be  
solely based upon some header being falsified.
If 'ADV:' on the subject line were to mean "this is not spam," then  
of course every spammer would use this label.  If it were used  
conscientiously to genuinely indicate an advertisement to an  
individual requesting such information, then of course such a message  
should not be filtered.  As there must be a mechanism based upon  
reputation to determine the integrity of the sender anyway, such  
labeling would be of extremely little value.  Assume responsible  
senders would cease sending advertisement when requested, and that  
such responsible senders also predicate sending based upon a request  
or granted permissions.

> In any case, may I suggest you respond to me privately or in an  
> appropriate forum e.g. asrg, since I think content labels are not  
> part of DKIM (of course DKIM can be applied to sign such labels).
DKIM itself could be viewed as a type of label that can be verified.


The domain of a compromised router does not need to be within the  
recipient's domain, as you indicate.

There is a difference between a black-list and a black-hole list,  
where black-hole list would be the preferred terminology describing  
an IP address qualification mechanism.

The path based registration schemes are very prone to intra-server  
attacks, in addition to man-in-the-middle attacks.  Many MTA are  
shared by multiple domains.  There should be some mention that  
mailbox-domain authorization schemes attempt to base authorization  
upon visible headers, where this then violates normal conventions.   
This is also true for SSP.  The solution often used for cases where  
authorization would inadvertently cause a message to be lost, is to  
use open-ended authorization.  Open-ended authorization may invite  
exploitations and may cause messages to placed into "junk" folders,  
rather than rejected with an indication of a delivery failure.
Your "ALL" chart lists '+', where this could be seen as the  
"politically incorrect" mode.  The normal approach would be to use  
the open-ended '?' mode.  Characterization of path based registration  
as being simple to implement or alluding to lower CPU overhead is  
misleading.  These path based schemes may require an inordinate level  
of DNS lookups consuming limited I/O resources, whereas CPU resources  
used for cryptography are generally available and otherwise unused.


You also question the value of utilizing reputation based upon the  
domain.  The domain does carry more information than just the IP  
address.  IPv6 addressing may create a similar situation.  A name  
offers the age and the registrar of the domain.  When considering the  
number of shared MTAs, the use of path registration remains dubious,  
whereas being able to verify the name offers greater value.  Even  
with DKIM, the mailbox-domain may not be assured and not be  
verifiable.  This is also true for the path registration techniques.   
Authorizing a mail service _does not_ indicate that mailbox-domain  
originated the message.  There is far greater risks associated with  
"poisoning" reputations based upon mailbox-domain authorizations,  
which are mechanisms being currently proposed.  Basing reputation  
upon DKIM signatures should eliminate most poisoning concerns.  This  
would assume that a replay mechanism is in place.

Although some see BATV and SES as similar solutions, I would rather  
see BATV used as an example for signing the bounce-address.  See Dave  
Crocker's explanation regarding the differences between these  
approaches.
http://www.mhonarc.org/archive/html/ietf-asrg/2005-06/msg00033.html

-Doug













_______________________________________________
ietf-dkim mailing list
http://dkim.org