Wow, lots of good feedback! Several replies follow:
On 2/13/2004 7:47 AM, Arnt Gulbrandsen sent forth electrons to convey:
> <foregoing discussion snipped>
>
> Anyway, I think the possibility of e.g. a future MAIL FROM test is
> reason enough to __permit__ the refusal to happen at any stage of the
> SMTP/LTMP process.
I intend to remove the text "to an end of DATA command " so that in no
case does the draft stand in the way of this.
I think Sieve implementations supporting pre-DATA refuse is a desirable
goal.
For example, LMAP could well make pre-DATA refuse more even more useful
than RBLs and envelope checks already do.
And folks who want to receive all email addressed to them, completely
"uncensored", can do so in a new way if there's a pre-DATA Sieve
processing/operating mode.
It's beyond the scope of this draft to explicitly facilitate it, so how
'bout a separate thread on a pre-DATA Sieve processing/operating mode?
I prefer to not add excess verbiage explicitly allowing things that are
already allowed, but we could (reluctantly) add:
"SMTP refusal may happen at any stage of the SMTP/LTMP process, up to
the end of DATA command."
I like Cyrus' idea of the refuse extension simply changing the semantics
of "reject" for several reasons.
It's the best way to make mass search-and-replace unnecessary when
switching from an MTA that can support "refuse" to an MUA that can't.
It makes it easier for folks to switch to using "refuse".
I can't think of a situation where you would want both reject and refuse
available at the same time.
Err, Arrgh - Kriskin Hubner came up with one: "reject" results in
friendlier emails than "refuse".
I find that many people don't understand even 'friendly' refuse messages
- e.g. a doctor's and an economist's email to me were refused with a
friendly refuse message, and yet they failed to act on it. Perhaps the
format of "refuse" messages is actually MORE easily comprehended because
it's less unique.
(email |bugzilla3sd(_at_)matthewelvey(_dot_)fastmail(_dot_)fm
<https://www.fastmail.fm/mail2/?MLS=MR-(_at_)0,7020,;SMB-MF-SF=4_1;SMR-Part=;SMR-MsgId=7020;Ust=f496ae4c%21227841ae;SMR-FM=1;SMB-CF=40145;UDm=49;MSignal=MC-FromName(_at_)0,%257Cbugzilla3sd%2540matthewelvey.fastmail.fm%21U=1>
to see my | 'friendly'
refuse message|.)|
(Regarding the other issues raised: I believe that anyone who would
receive an email that was rejected would receive that email if it was
refused as instead, unless they had weird email filters in place, so
don't think that's an issue. Also, I can't recall seeing a bounce that
didn't include the rejection text; what MTA's bounces don't ?)
|3 of us like it.
Kristin, further thoughts? Can you clarify whether SMTP rejection text
can use another charset? I get email (spam) with Subjects in all sorts
of charsets, imagine this would work too, but I'm (obviously) no expert.
|
On 2/13/2004 12:29 PM, Mark E. Mallett sent forth electrons to convey:
>On Fri, Feb 13, 2004 at 10:59:01AM -0500, Cyrus Daboo wrote:
>
>
>One might even add an option
>to "reject" to specify the SMTP response code and the extended result
code,
>which could be used in the smtp-time mode and ignore otherwise.
Alexey and I had considered this and decided that the added complexity
of allowing the user to specify the SMTP response code was outweighed by
the meager benefits of providing it. We even wrote (and later removed)
a long text on how to allow user-specified __extended__ codes to be
supported.
"Experience with many protocols has shown that:
protocols with few options tend towards ubiquity, whilst
protocols with many options tend towards obscurity."
- RFC 1651
Have a compelling argument for the option?
In any case, I will s/5.7.0/5.7.1 in the draft (in the section that may
or may not make it into the next revsion).
>Re the draft text: why is it "test refuse" and not "action refuse" ?
>
>
Because I made a mistake :).
I will be mostly away from email next week.
--
Matthew