ietf-mta-filters
[Top] [All Lists]

Re: draft-elvey-refuse-sieve-02.txt; http://wiki.fastmail.fm/wiki/index.php/SieveExtensionsSupportMatrix

2004-08-10 17:27:59


On Aug 10, 2004, at 4:18 PM, Philip Guenther wrote:


Kristin Hubner <kristin(_dot_)hubner(_at_)sun(_dot_)com> writes:
..
I'm sorry I missed the discussion, as perhaps the issues I will repeat
below have been already discussed.

Ned brought this up and it was discussed.


...
So either: (1) A "relaxed" reject action would need another parameter
specifying whether SMTP level rejection vs. later MDN should be
performed, and then the value of that parameter would need to
affect what sorts of characters are allowed in the reason string,
or else (2) A "relaxed" reject action would need two parameters,
one being the SMTP rejection text (ASCII only) and a second parameter
would be the MDN text which would allow non-ASCII text.   Or maybe
some third approach  I haven't thought of, as long as it allows
non-ASCII text when non-ASCII text is legal, and uses ASCII text
when ASCII text is required.

At the lunch meeting, it was felt that (2) was the preferable way
to resolve this, but that the details should be worked out on the
list.

I also prefer (2).


IMHO, reject should only send an SMTP-level reject if "given
permission" by an additional tagged argument.  If this argument was
given but the implementation was unable to perform rejection at the
SMTP-level for any reason, then it would send a MDN as if the
argument hasn't been given at all.

Ok, this is sounding good to me: if the latest plan is to extend "reject" by adding some explicit "do-refuse-if-possible" tag and include both possible texts, then that satisfies my concerns. I was under the (clearly wrong) impression that the latest
plan was that just one text would suffice.

In such a case, though, it's still not clear to me why extending "reject" with a "refuse-if-possible" tag and two texts is then necessarily any simpler than making a new "refuse-if-possible" action with two texts. But I don't have any objections to the
way that such an extended "reject" would work.

It would be nice if the script could not only specify the SMTP
response text but also the last two digits of the enhanced status
code (i.e., y and z in the "x.y.z" after the SMTP status code),
either via another tagged argument or by pulling them from the start
of the response text whenever it starts with
        1*3digit "." 1*3digit SP


...
And I think that the necessity for scripts to be aware of the
difference between SMTP rejection and MDN rejection means that
they might as well be coded with different actions -- I think that
there is no real simplicity benefit to using a single action.

I disagree: just because the text for the two may be different
doesn't mean I want to be forced to choose which of the two is done.
I would prefer to be able to say "do an SMTP-level reject if you
can with _this_ text, else send an MDN with _this_ text".

Yes, I agree that that is exactly what users will tend to want.



The "portable script" argument only works for sites that are
supporting English-only (or at best, Western-European-languages-
that-can-be-adequately-represented-in-ASCII-only) user communities.

For other sites that are already using reject with MDN text that
is not ASCII-only, their script already isn't suitable for SMTP
reject time interpretation.  Such sites are going to have to care,
in their scripts, about the different requirements for reason text
for SMTP rejections vs. MDNs.

If specified as I suggested above, these scripts would see *NO*
change in behavior.

Yes.

Regards,

Kristin



Philip Guenther



<Prev in Thread] Current Thread [Next in Thread>