ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Change the SSP o= to use words, break out 3rd party?

2005-11-08 16:53:55

----- Original Message -----
From: "Jim Fenton" <fenton(_at_)bluepopcorn(_dot_)net>
To: "william(at)elan.net" <william(_at_)elan(_dot_)net>
Cc: "IETF DKIM WG" <ietf-dkim(_at_)mipassoc(_dot_)org>
Sent: Tuesday, November 08, 2005 12:30 PM
Subject: Re: [ietf-dkim] Change the SSP o= to use words, break out 3rd
party?


Somewhat at odds with this is the t= flag, signifying testing.  We
should recognize it for what it is, a request to the verifier/recipient
to "be gentle" in the event of a failure.

And my receiver will say,

    "ok, but you better hurry up with your Migration and Testing,
     because this behavior will not be acceptable over an
     extended period. I'll be watching you. And by the
     way, your 1 year test key expiration is way too long.
     I will limit this behavior of yours to X month(x)."

In my view, TEST MODE is a very unique operation. It basically says, you
ain't ready for production mode operations.  So anything that comes out of
it should be viewed as void.  This should be one mode that is watched by
receivers and clocked for long term usage.

This is a threat entry point.

It's worth discussing whether
it is appropriate for such requests to be part of SSP, or conversely
whether there should be finer granularity in such requests, e.g.,
"suggest you delete non-conforming messages" or "suggest that you tag
the subject line of such messages".

Of course, local systems have the ultimate say simply because it could be a
bad actor telling the receiver how it should view failures.

While we're on the subject of SSP, Doug Otis remarked to me yesterday
that he feels that the existence of r= (reporting address) in SSP only
invites abuse; it's reasonable to solicit [abuse] reports on signed
messages but not on unsigned ones.  I think this deserves consideration.

Right, another threat.  Local systems have the ultimate say. Any
instructions beyond that of the inherit protocol consistency can not be
trusted.  Of course, it can be a local policy based concept per domain:

   AllowDKIMReports  @friends_list

In fact, I wouldn't be surprise if High-Value domains will pay a small fee
for such abuse reports. :-)

All I am saying is that anything abstract and relaxed is going to be ignored
by the receiver when it becomes a source of abuse.   I think a feedback
concept would be helpful for many parties, including the DMA.  The local
system has the ultimate ON/OFF switch.  It may also be a short time or 1
time only report idea.

        "You got a problem and this is our last feedback on
         the matter. Or future failures will be rejected."

Implementation crumbs, of course.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com




_______________________________________________
ietf-dkim mailing list
http://dkim.org