Collection of use cases for SSP requirements

[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

On Fri, 10 Nov 2006 03:15:55 -0000, Jim Fenton
<fentoncisco.com> wrote:

> 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.

I would have thought so.

And I would have thought it extrememly bad practice for any
ISP to be  
dropping any mail unless there is a specific opt-in, whether
it would be  
unlawful to do otherwise, or not.

For example, my own provider offers a service to run
Spamassassin, which I  
have gladly accepted. But I had to take positive action to
turn it on  
(there is a form on their website for doing that alongside
lots of other  
configuration options, including the Spamassassin level at
which you want  
the cutoff, and whether you want it dropped in the bit
bucket of just  
marked.

I am in the EU BTW, and have not heard of any problem with
this sort of  
filtering, which is quite widespread AIUI. Indeed our Post
Office has an  
obligation to deliver whatever is sent (even Craig Shergold
could not  
avoid that), but certainly in the UK ISPs are not Common
Carriers, just as  
they are not in N. America.
>
> 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.

-- 
Charles H. Lindsey ---------At Home, doing my own thing-----
-------------------
Tel: +44 161 436 6131                       
   Web: http://www.cs.man.ac.uk/
~chl
Email: chlclerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE
, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E
8 64 7E 14 A4 AB A5
_______________________________________________
NOTE WELL: This list operates according to 
http://
mipassoc.org/dkim/ietf-list-rules.html

>[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

Charles Lindsey wrote:
> On Fri, 10 Nov 2006 03:15:55 -0000, Jim Fenton
<fentoncisco.com> wrote:
>
>> 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.
>
> I would have thought so.
>
> And I would have thought it extrememly bad practice for
any ISP to be 
> dropping any mail unless there is a specific opt-in,
whether it would 
> be unlawful to do otherwise, or not.
If you go to the message that Pat Peterson wrote that
started this 
thread, that is exactly what some domains would like to do. 
They 
consider SSP to be helpful to counter phishing [Please,
let's not 
re-open that question; it has been discussed to death] even
if it is 
ineffective with look-alike domains and such.  The
requirement for the 
recipient to opt-in to have unsigned messages from their
domains removed 
diminishes that perceived benefit greatly.

-Jim
_______________________________________________
NOTE WELL: This list operates according to 
http://
mipassoc.org/dkim/ietf-list-rules.html

Jim Fenton wrote:
> If you go to the message that Pat Peterson wrote that
started this 
> thread, that is exactly what some domains would like to
do.  They 
> consider SSP to be helpful to counter phishing [Please,
let's not 
> re-open that question; it has been discussed to death]
even if it is 
> ineffective with look-alike domains and such.  The
requirement for the 
> recipient to opt-in to have unsigned messages from
their domains removed 
> diminishes that perceived benefit greatly.


(I mean to post a thank-you to Pat for his note.  That kind
of market research 
is always helpful.)

Oddly, Pat's research adds an interesting challenge for the
wg.  End users state 
end-state goals.

They are not attempting to specify a path to achieve it. 
That's our job.

Standards groups often try to specify all of a complex
solution, because they 
are trying to respond exactly to the (imagined, perceived,
or researched) 
end-user's description of what they want.  It is what
usually kills really 
interesting efforts, because the task is too complex, in its
entirety, to do all 
at once.

So, I claim, our challenge is to take the end-user desire
and figure out an 
initial deliverable that is as small as possible, while
still providing real 
utility to the end-user, even if that utility is not a
complete "solution" to 
whatever they have asked for.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
NOTE WELL: This list operates according to 
http://
mipassoc.org/dkim/ietf-list-rules.html