Re: Filtering

[Pawel Salek <pawsa theochem kth se>]

On 26 Jan, Tage Borg wrote:
> 
> Yes, ideally the MTA should handle the filtering. However, it is not
> uncommon that the user has no control over the MTA. Consider my ISP: I can
> connect and retrieve mail by POP3 (only) and I have no shell access. [..]
  Here we come to a point: should balsa be MUA or MTA, or both? I would
  prefer to focus on the first goal. I would even consider handing out
  jobs like downloading mail from POP/IMAP servers to a tool like
  fetchmail (anyway, it's mail transport task, isn't it?) I would
  possibly leave exception to IMAP, as it allows remote modification of
  the mailbox. Even in such a case one can always download mail a'la
  fetchmail to the local box. Anyway, it seems quite speculative to me
  to consider such twisted cases.
  Alternatively, balsa can do downloading itself but in fashion similar
  to fetchmail, i.e. utilizing local MTAs.
  
> 
> Also: if a user doesn't run balsa on their MTA, how would balsa write to
> .procmailrc on the server? Mail account usernames and/or passwords are not
> always the same as the shell login usernames/passwords.

  (MTA stands for 'mail transport agent' - like sendmail, I think the
  first sentence of this paragraph is some kind of misunderstanding).
  Even if you don't run filtering-enabled MTA on your mail server, you
  can still tranfer remote mail to local MTA you can enable yourself.

By the way, I wonder how one could do mail filtering on the mail server
without access to files (including .procmailrc) there? Filtering
implies additional mailboxes... I think IMAP only can do it.


> I personally don't care much about filtering, since I do it with procmail on
> my MTA and then fetch my mail with IMAP. But there are lots of circumstances
> that prohibit relying on procmail for ordinary users. Let's not forget that
> not all users have access to their mail server, let alone run it themselves.
> I even consider it likely that most users (even the vast majority) have *no*
> control over their MTA and any filtering done there. And most un*xes do not
> have procmail installed by default anyways.

  I am not aware of any circumstances that make ordinary user unable to
  take advantage of procmail. If the system administrator is able to
  install balsa, installation of procmail won't be more difficult. Even
  if the administrator doesn't agree to install procmail (in what I
  personally don't believe since they probably use procmail themselves)
  you can set up procmail yourself using .forward approach (I recommend
  procmail(1), it makes an interesting reading).

  Again, I don't think that the fact that _some_ un*xes don't come with
  procmail makes an argument against it: they come without balsa, too.
  And all Linux brands I know do come with procmail.

  About procmail invocation: Linuxes come often with such a sendmail
  configuration that use procmail as handler for so called local mail
  so no .forward file is necessary in such a case (check if you have
  line 
Mprocmail [....]
  or similar in your sendmail.cf. If you don't you can still use the
  .forward approach.

Pawel