Tim Showalter wrote:
Sieve is designed to filter a message at time of "final delivery", a
deliberately open-ended term concocted to make it clear that it's supposed
to happen just before the message hits the message store, and only happen
once. I think this is enough.
Okay. I won't argue about that.
An interesting question: are POP clients supposed to be able to
generate DSN's? That might put some arguments on it's head. :-)
Why shouldn't they? They have all the envelope information they need.
If a message can't be given to the user but was delivered to the mail store,
the POP client is probably the only program that knows why.
Tim, I understand that, with the exception that Return-Path: might
not be available and you may therefore not be able to conform to the
following quote from RFC 1894 chapter 2 page 7 2nd paragraph:
"
The DSN MUST be addressed (in both the message header and the
transport envelope) to the return address from the transport envelope
which accompanied the original message for which the DSN was
generated. (For a message that arrived via SMTP, the envelope return
address appears in the MAIL FROM command.)
"
Anyway, a POP client generating DSN's does not make much sense to me.
The message has already reached it's destination, nothing can be done
to prevent a delivery.
No, I don't. Prohibitions against configuring your mailer to do something
dumb are not typically part of protocol documentation.
Hmm. You might not want to prohibit.
But you might want to discourage inappropriate usage.
Sieve scripts should be portable, and I know of no case where this isn't
true (other than the lack of non-INBOX-like mailboxes if a Sieve script is
run on a POP server).
Okay, I take that back.
I think I ment broken in the sense of doing undesirable actions.
Sieve was designed to be run on the server when the message is delivered as
part of the MTA. My definition of MTA is broader than yours; I think the
MTA writes to the mail store, you think the mail store takes the message
from the MTA.
So, we have to live with that. I won't push it any further.
Bounce can be implemented easily by any program that can connect to an SMTP
server given an RFC822 message, to the best of my knowledge.
Right. Writing a program is one thing. Giving end users the power of
bouncing is another. This is something that have a potential of
becoming available to millions of users.
And I still don't understand why an end user would want to cause an
automatic bounce. Why is this a desirable action? Your argument seem
to be that it can be technically done, therefore it have to be
provided.
--
Hälsningar/Regards
Tomas Fasth <tomas(_dot_)fasth(_at_)twinspot(_dot_)net>
tel: +46-13-218-181 cel: +46-708-870-957 fax: +46-708-870-258
TwinSpot is a subsidiary of EuroNetics Operation in Sweden