[Top] [All Lists]

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

2006-11-09 00:27:19
a) publishes that note.  So far so good.

b) publishes that note, and blames you when their
   users' poorly formatted mail disappears.  Not so good.

c) publishes that note.  I don't want their mail
   whether they verify or not.

A is good.  


B is not your fault.  No matter what you do, poorly configured senders will 
blame you.  They do it now, so this is no different than today.

Except that for those of us who want to make our users happy rather
than score points, we'll need to ignore the SSP from these guys.  So
if we need to do that, perhaps we should ignore SSP altogether and
pick up the relatively small set of A's some other way, as Steve A.

C is not the problem SSP is meant to solve.

Well, OK.  In one sentence, what IS problem that SSP is meant to
solve?  It would be helpful if your answer kept in mind that receivers
have no inherent interest in senders' policy.  It's only useful if it
helps their own systems work better.

NOTE WELL: This list operates according to

<Prev in Thread] Current Thread [Next in Thread>