Hi Matthew,
--On Wednesday, February 18, 2004 6:40 AM -0800 "Matthew Elvey (FM)"
<matthew(_at_)elvey(_dot_)fastmail(_dot_)fm> wrote:
|> Anyway, you could punt and say that a refuse implementation should use
|> SMTP/LMTP rejection _where_possible_, and allow an implementation to
|> treat refuse as reject if the implementation can't do anything else.
|
| I very much want the user to be able to know as conclusively as possible
| that if "refuse" is supported, then they will be refusing mail at SMTP
| time.
Frankly I doubt that the 'average' user will understand the distinction
between refuse and reject - 'power' users will. I would likely expect that
reject vs refuse is something that will be decided by site admins as a
matter of policy and they would configure their sieve web-frontends (or
other script generation tools) to use one or the other as appropriate with
just a single UI widget representing a 'reject' type action that the user
can pick.
Perhaps the following would be better:
A single new command 'refuse' that takes various arguments, the first of
which can be one of:
'mdn' - send an mdn rejection with supplied descriptive text
'dsn' - send a dsn rejection with supplied descriptive text
'smtp5' - send an smtp permanent failure - ascii text provided is sent with
smtp response
'smtp4' - send an smtp temporary failure - ascii text provided is sent with
smtp response
'default' - one of the above as a defined by site policy.
The only problem with this is knowing how to deal with the text for the
'default' argument - for mdn/dsn it can be utf8, but for smtp it can only
be ascii. Perhaps 'default' should take two strings - one utf8 one ascii -
but that is ugly!
--
Cyrus Daboo