[Top] [All Lists]

Re: Relay control in SIEVE ???

2003-10-31 09:48:23

Just my 5 cents. I have Brightmail installed in 3 MTA machines running 
proprietary software on Solaris. 

Brightmail includes a SIEVE implementation for filtering out site specific 
BAD email messages. 

After using this, I wish every MTA would have a SIEVE filtering capability 
so I don't have to learn all the different methods for filtering by the myriad 
MTA software out there. Since we have a filtering language RFC, why not 
use it? Let's simplify the world - it's complex enough. 

But the case in point is, SIEVE is intended for final delivery filtering, not 
at the MTA level.

But if anyone is interested enough they can produce MIEVE or similar, 
based on SIEVE but intended for MTA filtering... although I like better 
the idea of extensions to SIEVE. 


----- Original Message ----- 
From: <ned(_dot_)freed(_at_)mrochek(_dot_)com>
To: "Madan Ganesh Velayudham" <mganesh(_at_)india(_dot_)hp(_dot_)com>
Cc: <ned(_dot_)freed(_at_)mrochek(_dot_)com>; 
Sent: Friday, October 31, 2003 3:41 PM
Subject: RE: Relay control in SIEVE ???

Hi Ned,

Oops ! My assumption and understanding about sieve was
that sieve scripts can be executed when MTA recieves a
client request. Can't we have checks like, if the connection
is from... Like that ? Adminstrators can enforce restrictions
that "I don't relay even spam mails..." :)

Such checks could be added, I suppose, but they aren't there
now. Again, this just isn't what sieve is intended to be used for.

Thanks for your comments.

Do you suggest to have a generic mechanism ( out of sieve ) for
"don't relay" functionality at SMTP level.

No, I don't. I agree with Cyrus: This is an SMTP server administrative 
and moreover one that tends to be done in very server-specific ways. Having
gone through the exercise of designing one generic frameworks at the SMTP
server level -- the MADMAN MTA MIB -- I can tell you that this sort of thing 
VERY difficult to do in a meaningful way, assuming it can even be done at all.
And it definitely lies far outside of sieve's purview. The first sentence in
RFC 3028 abstract states:

  This document describes a language for filtering e-mail messages at time of
  final delivery. 

This really could not be clearer. We need to guard against mission creep,
especially since we have so much work left to do in the space sieve is 
intended for. (I count no fewer than 10 drafts in process that relate to


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