Hi Ned,
Thanks again 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:
I understand that this lies outside the scope of sieve. I
thought
we can leverage many sieve language semantics aspects to define
a new specifiation for MTA level controling.
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.)
Yaah ! I'm more happy to work in sieve wg.
Cheers,
MG