ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Updated implementation report

2010-10-04 11:02:19
  On 10/4/10 11:00 AM, Jeff Macdonald wrote:
 On Fri, Oct 1, 2010 at 5:40 PM, MH Michael Hammer (5304)
 <MHammer(_at_)ag(_dot_)com> wrote:
To pick on you a little, if a domain owner uses your approach to
authorize signing by an ESP1, what is the stable identifier we are
talking about? Is it specific to this customer or is it shared
across customers? Does the domain owner understand potential
impacts on their reputation (assuming domain based reputation
systems ever get off the ground in our lifetime)?

 We are advising our clients to create a sub-domain for DKIM
 identifiers. Something they control. Something not tied to their
 From:. For those that have multiple streams, we'd recommend creating
 DKIM identifiers for each stream. Using DKIM as it was intended.

Only when signed by the same domain (Author Domain)  matched exactly 
with the From email address domain can ADSP policy apply.  Retaining 
customers when your domain is heavily phished means having non-complaint 
messages rejected becomes a greater concern.

 What happens when the domain owner dumps ESP1 and goes to ESP2? Do
 they lose whatever (We assume fantastic) reputation they had? Do they
 go to square 1 or are they borrowing/renting reputation from ESP2? If
 they are borrowing/renting reputation from ESP2, how do they know
 that ESP2 isn't using their domains good reputation to help other not
 so good senders at ESP2? Diluting the badness so to speak.

This assumes reputation assignment ignores who registered the parent domain.

 There are of course bad ways to implement things. Some ESPs use
 shared IPs for new clients in order to meet the sending rates clients
 ask for on day one. We do not have that strategy. Client's go through
 a warming phase with IPs dedicated to them. With DKIM, they will
 either come with their own identifier and be able to continue
 business as usual or start with a new DKIM identifier. I'd advise
 against using an e-Dialog DKIM identifier.

This also ignores the ability of bad actors to send themselves signed 
messages they can then be redistribute because DKIM is not _required_ to 
capture the SMTP RCPT TO.  Any expectation of such would cause many 
messages to be lost.

I'm assuming this desire for 3rd party signing to have the same
weight as 1st party signing is somehow related to deliverability
and not abuse.

 Abusers can be 1st party signers. So I don't understand why there is
 a distinction being made between 1st and 3rd party.

The difference relates to compliance related with signing practices.  
With replay ability, DKIM is not easily leveraged as a basis for 
reputation.  Reputation will likely need something developed along the 
lines of public keys or certificates offered by SMTP clients, because 
these services can track where messages are sent.  Where messages are 
sent is often the basis for identifying what is abusive.

-Doug

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