procmail
[Top] [All Lists]

Re: procmail config

2001-01-18 04:28:21
At 08:43 2001-01-17 +0530, S. Jyotinarayan wrote:
first, stylized text isn't especially welcome in a forum typically used by people using unix mail readers.

I have absolutely no idea how to configure Procmail.

Start with the FAQs.  <http://www.procmail.org>

We want each employee to have a personal mail account. We have a company in the US that's hosting our web server and has given us 100 mail ids.

The location of your hosting company doesn't matter. If you're going to provide those details, you should probably provide details about where YOU are located or what your domain is (it isn't easily inferred from your hotmail account).

I have a Linux server as my mail server:

To be perfectyl clear this is YOUR server, not your web servers' server. Doesn't say that up here, but can be assumed further down.

Software: Red Hat Linux 6.1
   Procmail v3.13.1

You should be aware that this version is pretty close to two years old. The current as of this writing is 3.15.1

   Sendmail
Hardware:
   PIII 450 MHz, 128MB RAM, 20 GB HDD, internet connection.

"internet connection" ? If this is YOUR server, whether that "internet connection" is fulltime, or dialup, if it uses a dynamic or dedicated IP address, and whether it has an official externally resolvable hostname are important aspects to how you'd set this up.

If you have a dedicated IP address (and chances are, if you've been sending mail to others from it, and their servers haven't had a high incidence of rejecting the messages, you probably are dedicated - but that certainly isn't the test), then you can just DO IT THE RIGHT WAY, and use a proper sendmail configuration.

If not, then you need to carefully review the fetchmail manpage.

And I have in the network some 50 or so nodes with operating systems such as Win9x/ME/NT/2000, Mac, unix, linux.

Congratulations.  This impacts the mail config how?

I've configured the Sendmail program on my Linux server, and it's working fine. We are being able to send mails locally to one another. We are also being able to send mails from our respective nodes using outlook express/Eudora etc. via the Linux server to outside domains.

Good, you're like 95% of the way there.  Now just finish configuring sendmail.

Now my problem is how do I configure my Linux server to get mails that have been sent to our US-based web/mail server and forwader them to the respective employees.

Uhm, if YOUR server is on a dedicated IP, you make sure your sendmail is configured to accept mail for it's own domain, you change your MX records on your domain to point to it, rather than to your webservice host, you also let your webservice know that you're doing this so that they can change their sendmail config, and then the mail comes directly to you. You should probably have your webhost act as an MX secondary, which requires a minour tweak to the DNS, and their config shouldn't refuse mail on your behalf. If the webhost doesn't know what an MX secondary is, then perhaps you don't want to be doing business with them.

This is _entirely_ a sendmail and DNS solution - doesn't involve procmail at all.

What do i use Procmail, Fetcmail or anything else? If I use Procmail, please give me a detailed set of instructions on how i could go about solving my problem.

If you were to use Fetchmail, you'd be setting up a Fetchmail configuration file (or one really big Fetchmail with a bunch of different sections in it, one for each, so nearly the same) for EACH mailbox on the remote server so that it could pull down messages and deliver them locally. Since the individual users on the local machine presumably also have their own mailboxes (and if not, that's the sysadm's job to go about setting them up, and once again, has _nothing_ to do with procmail), there's no need to filter the inbound formail messages through procmail in order to manage their delivery -- each user should have a unique pop mailbox on the remote server.

BTW - handling the inbound messages yourself (with your server as your MX) has many benefits over fetchmailing them:

        1. You don't have to maintain fetchmail scripts for each user, or
        create new ones for new users.

        2. You don't have to ask your webhost to create a new mailbox each
        time you get a new employee or need a new internal address.  Likewise
        for simple (or complex) aliases.

        3. You're not limited to some arbitrary number of mailboxes.

        4. Because your mailhost is on YOUR network, your users aren't sending
        unencrypted POP passwords out across the internet to fetch their email
        (as would be the case with opening your ISP mailboxes with fetchmail).
        Although there are other login schemes, let's face it, most ISPs go
        with unencrypted POP mailboxes.

        5. When someone sends a 2 MB attachment to five people at your company
        (all recipients of the same message), your mail server will be
        delivered this message ONCE, which it will deliver (internally) to
        each of the users (thus, 2MB of internet traffic inbound).  Formail
        would fetch FIVE 2MB messages from the remote server (=10MB internet
        traffic inbound).

        6. If you get tired of your current webhost and move to a different
        one, your email is unaffected, because it comes directly to you,
        rather than to them.

        7. By running your own sendmail, you can configure it for realtime
        blackhole lists, etc. (you can do this via procmail as well, but at
        that point, the whole SMTP transaction has taken place).

etc - there are many other reasons that running your own mail server is beneficial.

sendmail help:  news:comp.mail.sendmail

---
 Please DO NOT carbon me on list replies.  I'll get my copy from the list.

 Sean B. Straw / Professional Software Engineering
 Post Box 2395 / San Rafael, CA  94912-2395

_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail

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