[Dovecot] transitional weirdnesses

[Mark E. Mallett]

On Tue, Aug 19, 2003 at 06:55:38PM -0400, Eric S. Johansson wrote:
> 
> Mark, I know you're just being polite.

I guess there's always a first time :-)


> So, to go to the next step, there are 4 components on the receive side of a 
> mail system, MTA, LDA, MPA, MUA; mail transport agent, local delivery 
> agent, mailbox presentation agent, and mail user agent.  Sendmail and 
> postfix are examples of mail transport agents.  Procmail is an example of a 
> local delivery agent. dovecot is an example of a mailbox presentation 
> agent.  And Eudora, Mozilla, outlook are all examples of mail user agents.

In my extreme ignorance, I have not heard of the term "MPA".  However
it does seem to fit.


> if I understand you correctly Mark, you think that putting filter and 
> plug-in facilities into the local delivery agent would be the appropriate 
> place.  Please correct me if I'm wrong.

I dunno.  Maybe I was just spouting off too much.  I do think that
filters that are designed to accomplish mail delivery are most
appropriate in the delivery agent.  But I am also in favor of having
controls at various stages.  The filtering controls at the MTA level
are not likely to be the same as those at the delivery agent level--
here, I use both.  And I suppose I can see where there might be a
demand for filters that are active when the mail is fetched from the
mailbox server (e.g. between IMAP server and mail user agent).  But is
something like Sieve the right fit there?  Sieve is designed to
control what happens to mail on delivery.  (One might have such
filters at the user agent side inasmuch as there is delivery to local
folders going on there.)  All I really said was that if you want to
have filters that control how mail is filed on the mailbox server,
have a mechanism to re-deliver the mail so that new delivery filters
can be applied.  This would isolate the delivery logic to one place.
I would think there would be a different set of requirements for
filters (or selection criteria) that are engaged when the mail client
talks to the mailbox server.  And a lot of that is already present and
available by using the IMAP or POP3 protocol.


> Architecturally, I consider putting the filter in the LDA appropriate 
> because the filter operations happen at delivery time when it's appropriate 
> not as you are trying to read your inbox.  It's also the appropriate place 
> to put other types of processing such as antispam and antivirus checking.

Well- there are conflicts.  One wants to conserve resources, but the
resources available are sometimes in opposition (horsepower on the
server, bandwidth between the server and the client, time and effort
involved to set up each client, the are all resources that have to be
juggled).  One puts filtering on the server in order to conserve
bandwidth between the server and client.  One puts heavy duty work on
the client system because doing so on the server can't scale.  (So
whereas I can't run a CRM114 analysis on every message that hits the
server, each client could do so on their own machine.)  One may
relegate virus checking to the client machine because the corrective
stuff has to be done there anyway if a virus gets through.  Etc.


> One interesting thing about this model is that it implies if you can push 
> mail around from the MPA, there is a question of whether or not you want to 
> replicate LDA functionality in the MPA and if so, how much?  or how much 
> common code can a LDA and MPA share?  Is there a different architectural 
> structure where all inbound mail is injected through common path.
> 
> I don't expect anyone to do anything about this.  I'm just treading the 
> ground to see what the terrain feels like.

(no comment, other than just nodding)

-mm-