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-boun...@ietf.org [mailto:marf-boun...@ietf.org] On Behalf Of Murray S. Kucherawy Sent: Tuesday, October 12, 2010 12:11 PM To: m...@ietf.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
_______________________________________________ marf mailing list m...@ietf.org https://www.ietf.org/mailman/listinfo/marf
_______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html