Patrick Peterson:
> I (respectfully) disagree with Wietse. I think it is very important for
> the sender to be able to express their desire to the receiver for how to
> handle mail in specified circumstances. I do not believe expressing this
> desire constitutes "telling receivers what to do".
>
> This is a very important point as many of the senders I know who want to
> deploy DKIM feel this is an important component. Large scale deployments
> of DKIM require significant time and testing before adequate confidence
> can be established of reliability. Once adequate confidence is
> established many senders want to request that receivers do not deliver
> unsigned or improperly signed messages.
>
> These senders are not under the illusion they can force receivers to do
> anything. But they feel it is a significant value to express their
> desire.
I agree with the sentiment that senders must be able to indicate
under what conditions mail is un/authentic. DKIM provides a more
reliable tool to rank mail than looking at the FROM header.
However, I disagree with the sentiment that senders can tell
receivers to "kill it, don't pass it on" as expressed here.
This implies that senders control the threshold at which receivers
discard mail. I consider this unrealistic.
More realistic, IMHO, is that receivers maintain control over their
threshold, and that they use DKIM as a tool to rank mail against
that threshold.
Wietse
> pat
>
> > -----Original Message-----
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] On Behalf Of Wietse Venema
> > Sent: Friday, June 08, 2007 6:19 AM
> > To: Hector Santos
> > Cc: IETF DKIM WG
> > Subject: Re: MX dot was (Re: [ietf-dkim] TXT wildcards SSP issues
> >
> > Hector Santos:
> > > I don't expect mail from this domain - kill it, don't
> > > tag it or mark it as bad for user's to see, kill it,
> > > don't pass it on. Its not ours! - If you do, it is
> > > no longer our responsibility as DKIM-BASE suggest it
> > > is."
> >
> > Enough is enough.
> >
> > I thought we already debunked the myth that SSP can tell receivers
> > what they should do.
> >
> > It's a sender signing policy. It's not a receiver disposition policy.
> > ====== ======= ======== ===========
> >
> > Sender != Receiver
> >
> > Signing != Disposition
> >
> > I am of course assuming that this forum is conducting business in
> > plain English, not some variant with radically different semantics.
> > If my assumption is in error, please ignore this erroneous comment.
> >
> > Wietse
> > _______________________________________________
> > NOTE WELL: This list operates according to
> > http://mipassoc.org/dkim/ietf-list-rules.html
> >
>
>
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
