Filtering messages in MTAs

Arnt Gulbrandsen | 13 Feb 2004 11:28

Picon

Re: New Sieve extension "refuse" proposal - draft-elvey-refuse-sieve-01h


Matthew Elvey (FM) writes:
> http://www.elvey.com/it/sieve/draft-elvey-refuse-sieve-01h.txt

I suggest adding a sentence saying that SMTP refusal may happen at the 
RCPT TO or DATA stages, depending on what's convenient to the 
implementation. (I suppose it might also happen at the MAIL FROM stage, 
if a systemwide sieve does the refusal.)

The 550 result code is a fine thing, but shouldn't you also specify an 
extended result code (1893/2034)? 5.7.1, perhaps?

Arnt

Alexey Melnikov | 13 Feb 2004 17:59

Re: New Sieve extension "refuse" proposal - draft-elvey-refuse-sieve-01h


Arnt Gulbrandsen wrote:

> Matthew Elvey (FM) writes:
>
>> http://www.elvey.com/it/sieve/draft-elvey-refuse-sieve-01h.txt
>
>
> I suggest adding a sentence saying that SMTP refusal may happen at the 
> RCPT TO or DATA stages, depending on what's convenient to the 
> implementation. (I suppose it might also happen at the MAIL FROM 
> stage, if a systemwide sieve does the refusal.)
>
> The 550 result code is a fine thing, but shouldn't you also specify an 
> extended result code (1893/2034)? 5.7.1, perhaps?

This is an open issue in the document . Matthew and I weren't sure 
what to do with enhanced status codes.
Do you suggest that we mandate 5.7.1 or should we instead mention it and 
allow an MTA to select another enhanced status code if appropriate?

Alexey
__________________________________________
Isode Limited, http://www.isode.com

IETF standard related pages:
http://www.melnikov.ca/mel/devel/Links.html

Personal Home Page: http://www.melnikov.ca
__________________________________________

(Continue reading)

Arnt Gulbrandsen | 16 Feb 2004 16:07

Picon

Re: New Sieve extension "refuse" proposal - draft-elvey-refuse-sieve-01h


Alexey Melnikov writes:
> Arnt Gulbrandsen wrote:
>> The 550 result code is a fine thing, but shouldn't you also specify 
>> an extended result code (1893/2034)? 5.7.1, perhaps?
>
> This is an open issue in the document . Matthew and I weren't sure 
> what to do with enhanced status codes.

What's the problem? The description of 5.7.1 seems to fit refuse well, 
doesn't it?

> Do you suggest that we mandate 5.7.1 or should we instead mention it 
> and allow an MTA to select another enhanced status code if 
> appropriate?

Either would be fine, I think.

Arnt

Cyrus Daboo | 13 Feb 2004 16:37

Re: New Sieve extension "refuse" proposal - draft-elvey-refuse-sieve-01h


Hi Arnt,

--On Friday, February 13, 2004 11:28 AM +0100 Arnt Gulbrandsen 
<arnt <at> gulbrandsen.priv.no> wrote:

| I suggest adding a sentence saying that SMTP refusal may happen at the
| RCPT TO or DATA stages, depending on what's convenient to the
| implementation. (I suppose it might also happen at the MAIL FROM stage,
| if a systemwide sieve does the refusal.)

But SIEVE has to operate on the message data - there isn't enough 
information before the DATA command to run SIEVE, unless you extend SIEVE 
with tests for SMTP-Envelope data (e.g. a MAIL FROM test). Frankly any 
system-wide script like that is better left to the SMTP implentation's own 
filtering/ruleset behaviour.

--

-- 
Cyrus Daboo

Tony Finch | 13 Feb 2004 17:01

Picon

Re: New Sieve extension "refuse" proposal - draft-elvey-refuse-sieve-01h


Arnt Gulbrandsen <arnt <at> gulbrandsen.priv.no> wrote:
>
>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.

There's already an envelope from test in RFC 3028.

Tony.
--

-- 
f.a.n.finch  <dot <at> dotat.at>  http://dotat.at/
CROMARTY FORTH TYNE DOGGER: WESTERLY VEERING NORTHERLY 3 OR 4. OCCASIONAL
RAIN. MODERATE OR GOOD, OCCASIONALLY POOR IN DOGGER.

Arnt Gulbrandsen | 13 Feb 2004 16:47

Picon

Re: New Sieve extension "refuse" proposal - draft-elvey-refuse-sieve-01h

Cyrus Daboo writes:
> But SIEVE has to operate on the message data - there isn't enough 
> information before the DATA command to run SIEVE, unless you extend 
> SIEVE with tests for SMTP-Envelope data (e.g. a MAIL FROM test).

As I remember the draft I read, a spamtest implementation can legally 
arrive at a conclusion without considering the body, so if the script's 
first rule is a spam test, the body need not be considered. (I agree 
that the body will almost always be considered.)

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.

> Frankly any system-wide script like that is better left to the SMTP 
> implentation's own filtering/ruleset behaviour.

Sure, but that own filtering behaviour might just be sieve ;)

Arnt

Alexey Melnikov | 13 Feb 2004 17:55

Re: New Sieve extension "refuse" proposal - draft-elvey-refuse-sieve-01h

Arnt Gulbrandsen wrote:

> Cyrus Daboo writes:
>
>> But SIEVE has to operate on the message data - there isn't enough 
>> information before the DATA command to run SIEVE, unless you extend 
>> SIEVE with tests for SMTP-Envelope data (e.g. a MAIL FROM test).
>
> As I remember the draft I read, a spamtest implementation can legally 
> arrive at a conclusion without considering the body, so if the 
> script's first rule is a spam test, the body need not be considered. 
> (I agree that the body will almost always be considered.)

In theory any Sieve script that doesn't test message headers/body can be 
executed before DATA command.
But the task of checking if a Sieve script doesn't require message 
content might not be a trivial task. Especially if the Sieve engine also 
supports variables.

So I would rather ignore the issue of executing Sieve scripts before 
DATA command in the Sieve "refuse" extension.

> 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.
>
>> Frankly any system-wide script like that is better left to the SMTP 
>> implentation's own filtering/ruleset behaviour.
>

(Continue reading)

Cyrus Daboo | 13 Feb 2004 17:10

Re: New Sieve extension "refuse" proposal - draft-elvey-refuse-sieve-01h


Hi Arnt,

--On Friday, February 13, 2004 4:47 PM +0100 Arnt Gulbrandsen 
<arnt <at> gulbrandsen.priv.no> wrote:

|> But SIEVE has to operate on the message data - there isn't enough
|> information before the DATA command to run SIEVE, unless you extend
|> SIEVE with tests for SMTP-Envelope data (e.g. a MAIL FROM test).
|
| As I remember the draft I read, a spamtest implementation can legally
| arrive at a conclusion without considering the body, so if the script's
| first rule is a spam test, the body need not be considered. (I agree that
| the body will almost always be considered.)
|
| 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.

If you are going to run a script before DATA then you are going to have to 
limit the set of available sieve tests to just those that make sense - in 
other words you need to define different 'profiles' of the sieve syntax 
that are valid for different phases of the message delivery process. I 
think it would be a mistake just to say that certain tests (e.g. for header 
addresses) become no-ops when run before DATA. As such I think that a 
document that defines such a profile would allow the refusal on MAIL FROM 
or RCPT TO without needing to define that in refuse.

--

-- 
Cyrus Daboo

(Continue reading)

Return

Return to gmane.ietf.mta-filters.

Search Archive

Language

Change language

Options

Current view: Threads only / Showing only 20 lines / Not hiding cited text.
Change to All messages, whole messages, or hide cited text.

Post a message
NNTP Newsgroup
Classic Gmane web interface
XML

XML

RSS Feed
List Information

About Gmane