Subject: e: Appeal: Publication of draft-lyon-senderid-core-01 in conflict

From: Go Mehwua <[email-masked]>
Date: Fri, 26 Aug 2005 17:10:07 -0700 (PDT)

For e-mail policy, the sender's notion is not in play.
The receiver decides. <---- See that? It is a full
stop.  A period.  The end.

If the receivers decides to reject, discard,
post-on-a-blog any email that contains the letter "Z".
 Ok. They can.  If they decide that they will do the
same for any email some arcane piece of header is
right or wrong.  OK. They can.  They can even do it
when someone supporting sender doesn't allow them to
provide some data the receiver likes to have (Hi,
Frank  Ellerman!).

You put whatever you like in your records.  Enjoy. 
But you can't make people look at them.  You can't
tell them what to do when they read them.  Writing
down what they will do, and seeing if it is stupid, is
better than not writing it down.  

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 29 Aug 2005 22:56:38 +0200

Go Mehwua wrote:

 [various sender policies]
> you can't make people look at them.

Yes.

> You can't tell them what to do when they read them.

Not quite.  You're of course free to look at "my" policy,
decide that you don't like its redirect=, and stop your
evaluation at this point.  If you really hate redirect= 
you can also reject it:  "55x - I hate redirect="

What you can't do is to claim that the spec. tells you
to ignore (or reject) all redirect=  If you'd do this
it would be a lie, you'd be violating the specification.

Actually the same for _any_ specification, not limited
to SID / SPF / SSP / P3P / etc. - support it, ignore it,
break it as you see fit, your server, your rules.

The issue here with the first senderid appeal is that
it's _impossible_ for you to follow the SPF spec. and
the SID (PRA) spec. simultaneously if you want it. 

The second senderid appeal is about a similar issue
(if I understood it correctly), it is _impossible_ for
you to follow RfC 2822 and SID (PRA) simultaneously.

                       Bye, Frank