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.
Rgds,
-GSH
----- 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>;
<ietf-mta-filters(_at_)imc(_dot_)org>
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
function
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
is
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
actually
intended for. (I count no fewer than 10 drafts in process that relate to
sieve.)
Ned