[ietf-dkim] Re: Adding SMTP client Requirements

[Douglas Otis]

On May 29, 2007, at 11:44 AM, SM wrote:
> At 14:27 27-05-2007, Douglas Otis wrote:
>> As with any path registration scheme, paths must be known  
>> beforehand.  The DOSP scheme scales to accommodate _any_ number of  
>> paths.
>
> That would be like SPF.

SPF does not scale well and creates a significant DDoS concern.  Path  
registration is a PITA, however no other provisions are established  
for mitigating replay abuse.  This may cause messages not to be  
delivered when the RCPT TO can not be found within the message and  
when the SMTP client is not within the DKIM domain.  Opaque-ID  
records is another alternative, but this requires a response from the  
administrator.

>> Administrators could ask users to volunteer this information, or  
>> administrators could establish a forwarding service as a last leg  
>> of forwarded messages.  Those wanting this accommodation could be  
>> prone to a more spam when their account discovered, but the risk  
>> would only affect these users.
>
> It's an administrative burden.  We can always tell which path a  
> mail may take.

You mean we can't always tell?  Yes, some notification to customers  
would need to be made.  An administrator could establish temporal  
mailboxes that act targets for forwarded messages, which then are  
delivered to their main mailbox.  This approach should be easy to  
administer and not overly expose customers to replay abuse.

>> The concept is rather simple.  The bad-actor is a normal user of  
>> mail-abuse.org and sends themselves messages to other accounts.   
>> Mail-abuse.org rate limits accounts and promptly disables accounts  
>> reported and confirmed as abusive.
>
> You can have the same functionality with per-user keys without  
> placing any restriction on forwarding.

Per-user keys require the same level of administration as would  
Opaque-IDs, but per-user keys cause far more DNS traffic.  When email  
domains contain tens of millions of users, the amount of DNS traffic  
to support per-user keys is sizable and costly.

>> When DKIM serves as a basis for acceptance, without replay abuse  
>> mitigation, the bad-actor is still able to continue sending these  
>> messages to anyone and everyone until signatures expire.  They may  
>> have hundreds of such messages.  If mail-abuse.org grants public  
>> access to their service, the bad-actor could re-enroll and  
>> continue this behavior non-stop.  Replay abuse mitigation will become
>
> Your proposal does not prevent the bad actor from re-enrolling.

Although we are working on a list to vet enrollment, public access  
remains problematic.  Replay abuse allows bad-actors to bypass normal  
rate and recipient limits that are normally in place.  Providing a  
safe means to authorize SMTP clients for either MAIL FROM or DKIM  
domains is a proactive means forestalling abuse.  The administrator  
would not need to be immediately reactive in disabling per-user  
keys.  With high loads on DNS caused by per-user keys, lookup  
failures may become common and cause DKIM to be ignored altogether. : (

-Doug