Thanks Pat, this is useful feedback. Inline:
Patrick Peterson wrote:
3 months and 1300 mailing list posts ago, I wrote that I was going to
survey some senders on SSP use cases and report results back to the
list. At long last, here are the results.
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.
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.
The current taxonomy only has bullet 1 and something inbetween bullet 2
and 3.
There's quite a bit of contention about flat out stating what a receiver
should do,
which is quite reasonable: we really can't predict why receiver's do
what they
do (should a honey pot, for example, drop them too?). In the
requirements draft,
SSP was presented as being an information service first and foremost. In
that vein
it seems fine for a service to report some bogosity scale, but stop
short of declaring
the actual message disposition. In reality, if the protocol is
successful I can't imagine
that the receivers won't do exactly what you hope. But by not specifying
drop it
does save us from a really unpleasant rathole which is ultimately futile
for us to
specify anyway: a receiver will dispose of the message as they see fit
regardless
of what we say.
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.)
Here's a question: is this a severable problem from SSP itself? My
limited experience
with Murray's auto-magic error reporting in his DKIM milter is that this
a very
complicated problem and that we have not considered it in any depth.
What are the
security considerations (ddos?)? What is the reporting mechanism? What
exactly
do they need to glean from the report? Should these be summaried? What
about the
information leakage implications? Etc, etc. I'd be *extremely* nervous
to just throw
this in without much thought as the likelihood of unintended
consequences seems really high.
4.2. Problem Scenario 2: Illegitimate Domain Name Use
<snip>
3. A provides information that it signs all outgoing mail, but places
an expectation that it should arrive with an intact signature, and that
the receiver should be suspicious if it does not.
4. B could use this information to bias its filters such that it
looks much more suspicious.
A set of senders really want B to drop this email. Giving them to
vocabulary to state this is their desire. ISPs are of course free to do
as they see fit, but providing them with more granular information is
useful.
Yeah, but I'm afraid that actually offering disposition advise is going
to lead us
down that problematic rathole. Frankly, I'm rather worried about just
the opposite
of what you're customers have been saying: that receivers will
*overreact* to a
failed signature, especially in the 1st scenario.
Mike
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html