[Top] [All Lists]

Re: [ietf-dkim] Collection of use cases for SSP requirements

2006-11-07 21:48:39
 "Patrick Peterson" <ppeterson(_at_)ironport(_dot_)com> writes:

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.

Thanks for taking the time to do this.  I, for one, appreciate it.

It would also be useful to get similar insight from receivers.

[ ... ]             while the challenge of SSP is primarily to determine
what senders want to communicate to receivers and what receivers want to
know about senders policies/practices. SSP should provide a vocabulary
to senders that meets their needs and is useful to receivers -- this is
the most important requirement imho.

I completely agree with this.  SSP has to be useful for both senders
and receivers and it is all about communication.  You can't dictate
what receivers do, but many receivers *are* interested in hearing what
senders have to say and will take appropriate actions if what the
senders say will benefit them.

Another way to state this requirement is that there is a difference
- I sign all email, and
- I sign all email, treat unsigned or invalid signature with suspicion,

Can you please explain the difference between the above two?  Are you
saying the first one is really "I sign all email, but don't treat DKIM
failures as suspicious"?  Or, maybe the question is better phrased,
what is the difference between that and just an "I sign some email"?  

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

OK, as a receiver, can I blame the sender for any problems with
legitimate email being rejected due to DKIM failures?  If a receiver
can't transfer the blame to the sender, why should the receiver treat
this any different than just being suspicious?

Mind you, I've argued for this option as being potentially useful.  A
sender that discovers that someone is munging their email has options
such as sending with a different subdomain that just says "I sign
some", or working with the receiver to fix the problems, or telling
the receiver they have to change email addresses, etc.

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. 

Can you explain more about why people want an SSP which says "I send
no email" rather than just having an SPF record of "v=spf1 -all"?

A while back, I changed my opinion on this and I now think that both
are useful.  The SPF record covers the 2821.HELO and 2821.MAILFROM,
while SSP covers the 2821.From:.  These are all different and there
are cases where a domain can end up in the 2821 identities, but should
never show up in the 2822 identities and vice versa.

NOTE WELL: This list operates according to