On 9 Nov 2006 07:24:20 -0000 John Levine <johnl(_at_)iecc(_dot_)com> wrote:
a) paypal.com publishes that note. So far so good.
b) mismanaged-isp.com publishes that note, and blames you when their
users' poorly formatted mail disappears. Not so good.
c) paypal-payments.com publishes that note. I don't want their mail
whether they verify or not.
A is good.
Agreed.
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.
suggested.
People will do it wrong is an arguement that applies equally well to
DK/DKIM signing. In my testing of signing, I've had a message bounced back
to me because it had an invalid signature. As I understand it, this was
wrong for a number of reasons:
- The test flag was set.
- Invalid signatures aren't supposed to be treated any differently than no
signature.
- The message was sent via a known failure mode (a mailing list).
Additionally, but unrelated to DKIM, the bounce was sent to the 2822.From
and not the 2821.Mail From.
So, people are already twisting -base in ways it wasn't meant to be
twisted. Does that make it valueless?
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.
We've had this conversation before...
SSP can solve or substantially help exact domain forgery. Some of us think
that's useful,
some don't.
Scott
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html