Subject: Relay control in SIEVE ???

From: "Madan Ganesh Velayudham" <[email-masked]>
Date: Thu, 30 Oct 2003 09:54:12 +0530

Hi,

	Does sieve have control on relaying of mails at SMTP?

	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 .

	Please share your comments on this.

	======================================

	Syntax : dontrelay <reason string>
	
	SIEVE implementations that implement the "dontrelay" action have
an
	identifier of "dontrelay" for use with the capability mechanism.

	Capability name: dontrelay
	Capability keyword: dontrelay
	Capability arguments: N/A

	======================================
	
	Shall I come up with formal draft ?

	Thanks in advance for your comments.

	Sincerely,
	MG

	**************************
	Madan Ganesh Velayudham
	[email-masked]	
	+91-80-205-3108
	**************************
	+HP/STSD/Internet Services
	Bangalore, India

	Everything is possible

---

From: Cyrus Daboo <[email-masked]>
Date: Thu, 30 Oct 2003 11:20:06 -0500

Hi Madan,

--On Thursday, October 30, 2003 9:54 +0530 Madan Ganesh Velayudham 
<[email-masked]> wrote:

| 	Does sieve have control on relaying of mails at SMTP?
|
| 	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 .

Control of relaying is not a user action but an admin action and as such I 
don't see any reason why sieve needs to support it given that SMTP servers 
already have a way for the admin to control it. Perhaps you can explain why 
this should be built into sieve rather than just using the existing 
anti-relaying setup servers offer?

-- 
Cyrus Daboo

---

From: [email-masked]
Date: Thu, 30 Oct 2003 08:43:22 -0800 (PST)

> 	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.

> 	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.

> 	Please share your comments on this.

I don't think it is an appropriate sieve extension.

---

From: "Madan Ganesh Velayudham" <[email-masked]>
Date: Thu, 30 Oct 2003 22:53:12 +0530

Hi Cyrus,

	Thanks for your comemnts.

> anti-relaying setup servers offer?

	I'm not sure whether I understood the sentence "sieve is not
tied 
	to any particular operating system or mail architecture". And I
believe
	sieve can be used to do filter at the MTA itself.

	I don't know whether we have /generic mechanism/ by which the
relaying
	control is done at the MTA level. 

	I assume all users can have sieve scripts to filter their mails.
Does
	sieve documents describe anything about system level sieve
script ?
	Pls clarify.  I thought an administrator can have a sieve script
which
	can be executed when client contacts the SMTP server. The sieve
script
	may decide to refuse/reject to accept mail client connection.
But 
	administrator do not have an mechanism to say that I accept this
mail,
	but do not relay the mail.

	Please help me if I'm wrong.

	Thanks,
	+MG

---

From: "Madan Ganesh Velayudham" <[email-masked]>
Date: Thu, 30 Oct 2003 23:28:42 +0530

Hi Ned,

	Thanks for your comments.

> 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..." :)
> 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 )
?

	Please let me know your views.

	Thanks,
	MG

---

From: [email-masked]
Date: Thu, 30 Oct 2003 10:49:10 -0800 (PST)

> 	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.

> 	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

---

From: "Madan Ganesh Velayudham" <[email-masked]>
Date: Fri, 31 Oct 2003 18:32:33 +0530

Hi Ned,

> 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.
> 

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

	MG

---

From: [email-masked]
Date: Fri, 31 Oct 2003 07:41:16 -0800 (PST)

> 	"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

---

From: "Guðbjörn S. Hreinsson" <[email-masked]>
Date: Fri, 31 Oct 2003 16:48:19 -0000

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

---

From: "Madan Ganesh Velayudham" <[email-masked]>
Date: Fri, 31 Oct 2003 23:02:29 +0530

Hi Ned,

	Thanks again for your comments.

> 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 

	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 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

---

From: [email-masked]
Date: Fri, 31 Oct 2003 10:18:42 -0800 (PST)

> MTA software out there.

Please compare what you have written here with the subject of this thread.

Specifying filters that are applicable to more than one user, or applicable
to all users, is one thing. Specifying filters that control MTA behavior,
especially behavior as it pertains to detecting and controlling unauthorized
relay attempts, is quite another.

I view the former as being well within the purview of sieve. I view the
latter as being far out of scope.

> Since we have a filtering language RFC, why not

As it happens we have not one but two drafts in this general area:
draft-degener-sieve-multiscript-00.txt and
draft-daboo-sieve-include-00.txt. So this idea is already being pursued.

> But the case in point is, SIEVE is intended for final delivery filtering, not

The conflation of sieve with final delivery offers no real impediment to
performing system level actions.

				Ned

---

From: "Mark E. Mallett" <[email-masked]>
Date: Fri, 31 Oct 2003 13:33:58 -0500

> the idea of extensions to SIEVE. 

There are already good ways to tighten up mail servers against
relaying.  But I'm curious about what other MTA filtering you are
thinking of.  sieve (and sieve-like equivalents) can be used for
filtering things other than final delivery.  For example, we use
sieve filtering here for damping bounces resulting from bad
target addresses.  There are other pass-through kinds of filtering
that sieve-like programs could be appropriate for.  There are
other applications that they are not appropriate for (e.g. relay
control).

> From: <ned.freed>

Indeed- all of the drafts likely contain worthwhile things, but
cumulatively could have the effect of extending the language without
regard to language consistency.

mm