[Back on the original topic]
Good input, Pat; thanks. Comments below:
Patrick Peterson wrote:
Requirement #1. More aggressive practice options
Senders are concerned the current options aren't aggressive enough to
cause change in how spoofed email is handled. Without such a change
implementing DKIM is of little value to them.
The senders want to stop domain spoofing from impacting their brand and
customers. They want more aggressive policy statements that will more
aggressively encourage the receiver to drop spoofed email. It may be
some time before they are 100% signing and common errors that cause
signature failure for their mail are eliminated but they are focused on
realizing this as soon as possible. When this happens, they want to be
able to request that receivers drop signature failures or unsigned
email. For some, the cost of phishing is so high and some day the risk
of dropping messages will be so low that their inability to state a
stronger policy will impact their ability to reduce the impact of domain
spoofing.
Another way to state this requirement is that there is a difference
between,
- I sign all email, and
- I sign all email, treat unsigned or invalid signature with suspicion,
and,
- I sign all email AND have enough confidence in the reliability of
signatures AND the risk of allowing spoofed email is high enough that I
choose to accept the risk and therefore state that receivers should drop
unsigned/invalid signature email.
We have been very careful to be declarative rather than imperative in
SSP for the following reason.
Very early on (during the WG chartering process), we got input from
several people that laws in the EU prohibit an email service provider
from honoring instructions from a purported sender to drop messages from
others. From what I have been told, the [snail-mail] postal model is
followed closely: the delivery agent has an obligation to deliver the
message, even if it may be forged. I'm currently trying to get more
specifics on whether this is spelled out somewhere, or is just an
extrapolation of the delivery of "post". While this could probably be
resolved by having those subject to these regulations just not implement
message rejection, we didn't want the perception to be that DKIM
violates laws in some jurisdictions.
It may very well be that this is OK if the recipient opts-in for this
service, or something like that.
In any case, the notion of "Suspicious" was chosen to not be too
specific, but cover the case where the verifier (for example) rejects
messages which are suspicious.
I'll report back to the list when I get more specifics on the legal
aspects (or whether there was a miscommunication somewhere).
Requirement #2. I send no email.
Many senders have a large number of domains that are never used in
email. They want to be able to state this unambiguously. To the senders
I surveyed, the 'I send no email' policy is a unique case from the other
cases. I asked if they wanted this in addition to the SPF/SIDF '-all'
policy and they universally said yes.
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, which someone else asked but I missed the
answer if there was one. Having the information in more than one place
means you need to define what happens in the event of conflict.
2. "I send no email" is not really a DKIM policy, it's a mail policy.
I'm concerned about there being a slippery slope of policies if we
venture outside DKIM. But we can probably manage that, so this is more
of a principle than something that doesn't work.
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.
Requirement #3. Feedback of invalid signature/unsigned mail
Senders are concerned that the #1 item that will prevent them from
moving to aggressive practices is the inability to identify errors.
Errors on their part (failure to implement signing, improper signing),
receiver errors (noncompliant implementations of DKIM validation) or
anything else that Murphy's Law says will happen. They would like a
feedback mechanism to be defined that provides this feedback. Defining
this mechanism does not require it to be implemented by any receiver;
failing to define this mechanism makes it impossible to implement easily
for anyone. (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. Not a complete
solution as envelope sender not equal From: and mailing list traffic
doesn't originate from their IP space, but many felt this might be a
good compromise solution.)
Presumably this action would be independent of whether the verifier
rejects, discards, annotates, etc. the message when there is a failure.
I guess the 'postmaster' address must too overworked for this task.
There are a couple of ways to do this reporting:
1. Create a new well-known address that is used for reporting DKIM failures.
2. Include a reporting address in the SSP record.
In the case of #1 is that there would still need to be a flag somewhere
asking the verifier to send the problem report. In either case the
verifier should expect the address to be the recipient of a lot of
abuse. #2 has the advantage that it could be turned on for short
periods, or addresses could be rotated frequently enough that
(hopefully) the unwanted mail could be managed.
I'm not crazy about tying this to SPF records. I expect that some of
the problems that are reported via this mechanism will have to do with
unexpected forwarding through agents that modify the message in some
way, and in those cases SPF is also likely to fail.
-Jim
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html