I don't think this is really something this WG needs to deal with, though I
could be wrong. It's forwarded here just for informational purposes.
From: marf-bounces(_at_)ietf(_dot_)org
[mailto:marf-bounces(_at_)ietf(_dot_)org] On Behalf Of Murray S. Kucherawy
Sent: Tuesday, October 12, 2010 12:11 PM
To: marf(_at_)ietf(_dot_)org
Subject: [marf] An issue with DKIM reporting extensions
Here's another problem case with ADSP that directly involves the DKIM reporting
extensions.
Setup:
- Domain X evaluates DKIM and ADSP inbound.
- Domain Y's border MTA is configured to sign mail outbound and also
generate success DSNs on request. Domain Y posts an ADSP policy of "all", and
furthermore is using the draft-ietf-marf-dkim-reporting extensions to announce
it wants fraud reports about mail that fails ADSP.
Scenario:
- X sends mail to Y. The message requests a success DSN on delivery.
- Y receives mail. MTA generates success DSN as requested; however,
it's generated internally (an MTA design decision) and goes directly to the
outbound queue. It therefore does not go through the SMTP filters, and thus
isn't signed outbound.
- X receives success DSN. It is unsigned, as described. Therefore,
ADSP fails. X detects that the reporting extension is in use and observes that
Y wants fraud reports, so it generates one.
The MTA in question is widely deployed on the Internet. It does not have the
ability to change the domain in the From: field on DSNs it generates so as to
detach it from the published policy, nor can it filter generated DSNs through a
signing filter. Also, ADSP doesn't have a mechanism to exempt DSNs from ADSP
processing. This means some or all of the following:
- In order to make use of ADSP, Y needs to change which MTA it's
using. This is almost certainly an expensive effort.
- Y simply can't use ADSP.
- The DKIM reporting extensions should have a flag that says DSNs
should not cause generation of fraud reports.
Comments?
-MSK
ATT00001..txt
Description: ATT00001..txt
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html