Hi Ned,
Thanks for your comments.
Does sieve have control on relaying of mails at SMTP?
No. Sieve is designed to operate at or around the time of
final delivery. The language simply isn't oriented for use on
MTAs. In particular, sieve provides access to a limited
amount of the envelope, the message header, and maybe at some
point the message content. Conspicuously absent from this
list is access to the sorts of information an MTA has and
that are typically used to make relay decisions, such as
whether or not the client is considered to be "internal" or
"external", whether or not the session is authenticated, and so on.
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.
When I went through elvey's proposal on "refuse". Good one!
dontrelay :
Administrator of the domain can decide to accept the mails
but they donot want to relay mails to other. This requires
an extension "dontrelay" in sieve .
Even if you grant that use of sieve is appropriate in this
context -- and I don't think it is -- I have no idea what the
semantics of a "dontrelay" action would be. Sieve can cause
messages to be redirected or rejected, but marking them as
being ineligable for subsequent relay seems pretty problematic to me.
Yes. First Action would be to reject the mail and return
"Relaying
denied" message to the originator. It could be redirect the mail
to
"junk folder" or simply drop the mail.
Do we have a specification for this earlier ( generically also )
?
Sieve already has a reject action which could specify "relay denied",
a fileinto action to send the mail to a folder, and a discard action.
Ned