[ietf-dkim] Re: Adding SMTP client Requirements
dotis at mail-abuse.org
Tue May 29 14:53:04 PDT 2007
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
> 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
>> 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. : (
More information about the ietf-dkim