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.
pat
-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] 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