procmail
[Top] [All Lists]

Re: deactivating of /var/mail/$USER ?

2005-11-07 18:07:12
At 19:28 2005-11-07 +0100, Michelle Konzack wrote:
I am runing fetchmail + procmail + courier-imap and sometimes
I have unknown errors and $USER messages are going into
/var/mail/$USER which is inaccessibel to $USER.

I like to see an option, to disable this feature (!!!) and
return an error instead so fetchmail leave the message on the
server.

Is this possibel ?

I have more then 17.000 $USER on the Server

You have this many users and you're using fetchmail in place of a normal 
MTA arrangement?  The chief reasons to use fetchmail are running a home 
(personal) server that is on a dynamic connection, or for users on a 
regular server to fetch mail from remote accounts to bring them into one 
mailbox (once upon a time, I could fetch my yahoo mail this way, and 
there's a daemon that provides a LOCAL pop interface to hotmail, and 
enumerates and fetches the hotmail messages via http on the back end).

IMO, fetchmail is not well suited to mammoth user account 
arrangements.  Besides, if you really have that many local users, there's 
bound to be scores of messages which are not delivered properly (bcc's, 
etc).  Refer to the procmail mantra.

A far better arrangement would be to use a dynamic DNS setup (if your 
server isn't already on a static IP), and use fetchmail to do little more 
than issue an SMTP ETRN command to the mail server acting as your 
collection point.  No POP involved, and multiply addressed messages would 
route as a SINGLE message via SMTP.

I seem to recall you were operating over a dialup connection or 
somesuch.  How on earth can you expect to support so many users and not 
have a fulltime connection?

and it is no fun to get the "secured" messages back into the $USER maildirs.

Erh, if the messages end up in /var/mail/$USER, why not have a cron-invoked 
script (running from root, or the mail user) redeliver them to the 
appropriate imap folder?

If you have an "unknown error", I can't help but think that the best course 
of action would be to ISOLATE and fix it.

---
  Sean B. Straw / Professional Software Engineering

  Procmail disclaimer: <http://www.professional.org/procmail/disclaimer.html>
  Please DO NOT carbon me on list replies.  I'll get my copy from the list.


____________________________________________________________
procmail mailing list   Procmail homepage: http://www.procmail.org/
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail

<Prev in Thread] Current Thread [Next in Thread>