[Back on the original topic]
My objections to an "I send no email" policy in SSP, all flexible, are:
1. SPF/SIDF already says that. I'd be interested in why they want to
say this in SSP as well, ...
Presumably that's so that DKIM doesn't depend on SPF.
2. "I send no email" is not really a DKIM policy, it's a mail policy.
This is really the most important point, since this bit of policy is
just as useful to people who don't use DKIM and never will. There are
other proposals such as MX dot that let domain owners publish this bit
without the extra cruft of SSP or SPF.
3. I'd rather preserve the characteristic that the verifier doesn't have
to check SSP if there's a valid signature from the author (From
address). If we can define it that a valid signature overrides the "I
send no email" policy, this point is solved.
I sure hope so. The work to create a DKIM key pair and publish them
in one's DNS is greater than to set a flag in an SSP record, so in
case of collision, the DKIM record is at least as credible.
Requirement #3. Feedback of invalid signature/unsigned mail
Senders need to keep in mind that they're asking recipients to do them
a potentially large favor here, so if there's a mechanism it needs to
be really simple and easy for recipients to do. A flag encouraging
reports to a fixed well known address seems the simplest option.
(Without going too far down the solution avenue, senders felt one
possible solution to receiving an excessive number of
invalid/unsigned feedback emails during a large-scale spoofing
attack was to state that they only wanted feedback for emails which
originated from their IP space as defined by their SPF record.
Speaking as a receiver, that's a bigger favor than I am offering for
free. If senders want the feedback, it's their problem to weed out
the noise, not mine. If receivers out of the goodness of their hearts
want to do some prefiltering, they can figure out how to do so without
having it written into a standard.
R's,
John
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html