ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Re: Adding SMTP client Requirements

2007-05-29 14:59:17

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






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