Re: Filtering

["Tage Borg" <tage ckrakes com>]

Pawel:
>On 26 Jan, Tage Borg wrote:


[snip!]

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


Ah. What I meant was: User is on mymachine.foo.bar. MTA responsible for
recieving users mail is on mail.isp.com. User runs balsa on
mymachine.foo.bar, not mail.isp.com. (So MTA in my paragraph above should
have been MTA server ("the server that runs the MTA") or something similar,
sorry for being unclear). It is possible that user doesn't have shell access
to his ISP account or in any case doesn't have shell access that allows him
to control mail delivery and/or forwarding.

>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 too think that "server side filtering" is only useful for IMAP clients
(and some shell clients, Pine and Mutt come to mind). And with no shell
access...

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

I'm pretty certain the administrators that work for my ISP don't ever use
the mail servers user have access to for their own mail. No doubt they all
run procmail on the corporate mail servers, but customers don't have that
benefit...

>  you can set up procmail yourself using .forward approach (I recommend
>  procmail(1), it makes an interesting reading).


That's what I do, but I don't think all users have that option.

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


Yes, but not Solaris. Probably not HP/UX, AIX, Tru64, Irix, etc.

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


Yes, if you have shell access. Balsa would work just fine for me (if only I
could make it compile under Solaris 7, I think I'm going to have to switch
to Linux, even if support for my framebuffer is poor and I won't have any
sound), but I, like most of the people on this list are more priviliged than
most users both when it comes to un*x skills and when it comes to server
control and configuration. Shell access isn't a sure thing except on your
own machine. So in the end, If Balsa is to use procmail, it will probably
also need to use fetchmail or have similar functionality itself. And
filtering for POP3 users will have to be implemented in Balsa.

Hmmm. Months and months of lurking, and now this :)

    /Tage