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-