Hi,
We recently decided to implement DKIM in our organization.
While reading through the RFC, I found a possible case, where the
authentication is lost. (Sorry if it is already discussed and a known
issue)
Scenario:
Let's assume a spammer wants to spam email accounts on domain "X.com" and
the spammer uses a domain "Y.com". Both the domains have implemented DKIM.
1) For example, Spammer can create accounts in X.com & Y.com like
sample-spam(_at_)X(_dot_)com & send-spam(_at_)Y(_dot_)com
2) From send-spam(_at_)Y(_dot_)com the spammer can send a spam mail to
sample-spam(_at_)X(_dot_)com adding it in BCC and the mail is digitally signed.
Let's
assume the mail is delivered to sample-spam(_at_)X(_dot_)com
3) Now spammer can take all complete headers and body from
sample-spam(_at_)X(_dot_)com(including signature header) and he can send them to
all possible accounts
on X.com from botnets and not necessarily from Y.com
Note: Delivered mail won't contain "To:" header as the address was added
in BCC -- as mentioned in point (1)
However the above procedure has some cost -- Spammer has to create a sample
account on a domain (say X.com) to spam most of the accounts on that domain
(X.com). But the cost is very less -- advantage of spamming most of the
accounts by just creating a *sinlge* account.
Mail once signed can be used forever to spam others -- by making it to arise
from different botnets and giving an illusion that the botnets actually
signed a mail. Here DKIM fails to detect it and passes the mail completely.
One possible simple solution/suggestion:
- At outbound MTA add IP which is going to send mail along with the
signature (in some format) before encrypting.
- In inbound MTA decrypt the value and check if the mail arised from the
corresponding IP in addition to checking the signature.
The above suggestion would break, if a mail is forwarded by a domain on
behalf of some other account. But it has a work around by checking the
IP/Domain with the sender's domain.
Please let me know your comments. Sorry again, if it is already known and
discussed previously.
Thanks,
Thiyaga
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html