Subject: Are vacation and procmail MUAs?

From: "Woodhouse, Gregory J." <[email-masked]>
Date: Wed, 14 Jan 1998 20:13:48 -0600

I'm afraid I can't agree here. Whether procmail is used directly as an 
MDA or invoked through a users .forward, it is still invoke directly 
via sendmail. To me, this differs from MUAs which I think of as true 
clients (either sending mail via SMTP or receiving mail via POP or 
IMAP). The difference is that these types of clients may *call* the 
server (through a protocol), but are never *called*. On the other 
hand, procmail is invoked (indirectly) by sendmail, so it belongs in 
another category.

In all fairness, my definition of MUA may be more restrictive than the 
usual definition, but I believe this definition has the advantage of 
being more precise and clearly addressing the role of the program as a 
component of a message handling system.

Gregory Woodhouse [email-masked]
May the dromedary be with you.

----------
From:  Keith Moore [SMTP:[email-masked]]
Sent:  Monday, January 12, 1998 2:59 PM
To:  Matthew Wall
Cc:  Keith Moore; [email-masked]; Harald Alvestrand; Paul 
Hoffman
Subject:  Re: MTA Filters BOF request, LA IETF; Proposed Charter

> > with few exceptions, the mail transport system should not be
> > doing mail filtering.  the mail transport's job is to deliver
> > mail, not to make filtering decisions on behalf of the user.
> > if recipients want to filter their own mail, that's their
> > business, but then it's a UA-level thing.
>
> I disagree. Filtering is something that *is* done at the delivery 
end of the
> transport cycle. A "UA" relies on delivery and transport agents to 
make a
> number of decisions. If it was merely a UA activity, we wouldn't 
have
> vacation, procmail, .forward, IMAP BB+ -style delivery, 
auto-bouncing, or
> any current filtering activities done completely without the 
participation
> of a UA.

vacation and procmail *are* UAs, as are any programs to which mail is
forwarded for the purpose of filtering mail.

I can understand why a ubiquitous filtering language would be useful.
I can also understand how it could cause a great deal of harm, by 
making
the behavior of the mail transport system less predictable.

Defining only the language also ignores the security issues.   How
are users going to specify such filtering without some means of
authenticating themselves to the filter?

Keith

---

From: Andy Poling <[email-masked]>
Date: Wed, 14 Jan 1998 22:27:10 -0500 (EST)

> hand, procmail is invoked (indirectly) by sendmail, so it belongs in 

You're confusing functionality with who runs things when.  Procmail and
other processing and other forwarding software and functions can (and
should) operate independantly of the MTA, and they operate on the user's
behalf (even if the user didn't actually "run" them herself).

The fact is that you do sort of make a valid point in a backwards way, and
that point is that the MTA/MDA should *not* be running software on behalf of
the user.

And puh-lease stop saying "sendmail".  That is only one example of an MTA
(say it with me: "em-tee-ay").  There are other MTAs that (properly IMHO)
_don't_ run user-supplied programs on behalf of the user.

-Andy

Global Auctions
http://www.globalauctions.com

---

From: Steve Hole <[email-masked]>
Date: Thu, 15 Jan 1998 10:20:13 -0700

> that point is that the MTA/MDA should *not* be running software on behalf of

Interesting.   Why should the MDA not run software on the part of the user?
I can think of many reasons that doing so should be carefully engineered, but
I don't see any architectural reason for doing so.   An MDA, by contract, has
to have some kind of user specific knowledge in order to do per-user
delivery.   We are talking about extending that knowledge.

I think that of the problems has to do with the roles played by MTA and
MDA.   MDA is a fairly recent addition to the architecture.   It really has 
been the advent of smart message stores that require separate delivery agents
that has led to people referring to MDA's separate from MTA's.    In today's
reality, they are very different objects.   LMTP is a protocol designed to
formalize the communication between an MTA and MDA as separate objects.   They
have very different contracts.   I think that there is some role (contract) 
confusion between the two.

So, I will agree that an MTA probably should not be executing software on the
part of a user.   I say this because I believe the MTA's primary contract
is to move messages from source to destination. 

I propose that the MDA is responsible for final disposition of a message as
specified by the policy of the destination site.   Policy at a site may
be restricted to site defined rules for disposition, or the site *may*
choose to set up default dispositions for its users and delegate final
disposition authority to the user -- all appropriately authenticated and
access controlled.

Cheers.

---  
Steve Hole			VP,  Research and Development  
The Esys Corporation		EMail: [email-masked]
900 10040 - 104 St.		Phone: 403-424-4922  
Edmonton, AB, Canada		Fax:  403-424-4925  
T5J 0Z6