procmail
[Top] [All Lists]

Re: Need Help!!

2001-04-05 13:58:15
At 16:00 2001-04-05 +0500, Rizwan wrote:
Dear Sir,

Dearest Rizwan,

You have sent your message to a mailing list, not to an individual. A mailing list dedicated to the use of procmail, a UNIX-based mail processing facility. I stress UNIX based, since your message arrived as HTML based text with font tweaks like small sans-serif font and interspersed bolding. This doesn't jive well with unix mail readers.

Please use plaintext, not stylized HTML.

After the retrieval, Procmail performs the local delivery to the users' local home folders. A local user account "khi" is used for the fetchmail process. The .fetchmailrc and .procmailrc files reside in the /home/khi/ folder. Now the problem.....................

There are different ways for fetchmail to be performing the retrieval -- via a mailbox on the remote system (which means you have one global aliased mailbox on the remote system), or because the remote server is set up as an MX for your domain, and fetchmail is issuing an ETRN command to it to cause it to queue up the messages for delivery to your now connected mail server (not uncommon for servers which are not connected fulltime).

The ETRN method is preferred because each user is still a unique user. If you're downloading via a SINGLE POP mailbox, you will end up stuffed with the problem you're having.

My recommendation: if you're connecting with a STATIC (always the same) IP address, get the remote host to act as an MX for you, so that it queues up messages when you're not connected to the net. If you're on a DYNAMIC (changes when you connect), look into a DNS provider which supports dynamic DNS (such as zoneedit, with which I have no affiliation, and am not a user), then set up your server to be the primary MX for your domain, and your ISP server to be secondary (provided we are talking about a DOMAIN here, and not just some detatched mailserver). Communicate this to your ISP so that they can establish the appropriate changes (if nothing else, they shouldn't mail you at your ISP-hosted address, but rather at an address within your domain). Then, set up fetchmail (see the fetchmail docs) to perform an ETRN when you connect to the network (after you've established your dDNS update on connection).

Of course, mail simply servers aren't supposed to be operated on non-static connections, so the best solution is really to get one if you don't already have one. Even if the connection isn't fulltime, if the address is static, it's a big plus.

If you were fetching mail in this fashion, you would not need to use procmail to perform local delivery rerouting from a single remote mailbox, and as a result, shouldn't end up with the problem you're describing.

When I send mail to more than one user locally, or through Net, each user receives mails equal to the number of users specified in the Address Header. In other words, each gets copies of that mail equal to the numbers of users destined.

And some users, if not defined in the clear (i.e. as a BCC), don't get copies of the messages. This is a longstanding known limitation of multi-recipient delivery through procmail - the MTA isn't telling procmail who the individual message is addressed to, and the script is parsing the message to find the recipient.

While if a mail is sent to netadmins, every user in that alias receives three copies of that mail, since the users are three in number.

Let me guess, this khi account has a series of procmail rules like:

:0c
* ^TOuser1
!user1

:0c
* ^TOuser2
!user2

.. etc

walk through it mentally - each message will be delivered to each apparent recipient because the mail system produced THREE copies of the message and delivered them to one user who is then copying them to each of the apparent recipients.

I'm also attaching herewith a copy of my "/etc/sendmail.cf", ".fetchmailrc", & ".procmailrc" files.

Attachments are the bane of mailing lists. Esp. unix based ones, since most clients require the user to shell in order to view something which should have just been part of the message. Additionally, procmail isn't a support forum for sendmail or fetchmail, and the sendmail.cf is going to be a whopper of an attachment.

Bless my fibre optics, the attachments weren't attached.

Please assist me to find the exact problem and its location. Also I need help about the Procmail process. Please guide me through the whole process of my Mail's site.

You're kidding, right?

1) Is Sendmail involved in local delivery of mails to local users, within the local LAN?

Sendmail is involved in the delivery of mail, whether to local users or remote (and on the LAN, they're still remote to THIS machine). It resolves aliases, etc. If procmail is the LDA, then sendmail is invoking procmail for that task (after alias resolition), but sendmail is still part of the picture.

2) Does Sendmail service need to be enabled to perform the local delivery to local users within the LAN?

Sendmail doesn't have to be running as an SMTP daemon, if that's what you mean by "service". If sendmail (the program) isn't in the picture though, mail isn't going to be delivered. Any other hosts on the lan which mail may be directed to will need an SMTP agent in order to recieve mail (this being very different from client machines connecting to a single mail host and retrieving mail).

3) If Sendmail service is disabled, then who would be responsible for the local delivery of mails to local users?

Some other application you install to perform that function. Unix isn't going to go "gosh, no sendmail, let me find something else to do this job." If no application is installed to perform the job, the job won't be done.

4) After Fetchmail fetches the mail from the remote site, what are the steps performed at the local distribution of mails & when &
    where Procmail is involved?

See the fetchmail documentation, which isn't part of this forum.

5) What is the significance of "/var/spool/mail" directory, & when it's used by whom?

I think it'd be a good idea if you invested in the ORA _Sendmail_ book, and perhaps read up some FAQs (sendmail, procmail, formail, etc) before getting much deeper into this administration job.

/var/spool/mail is the "mail spool". It is where mail is stored until the users retrieve it with their mail reader (or if local procmail filtering automatically puts it into the user's mail folders)

6) Also help me to understand the Fetchmail & Procmail processes in this Mail Servers' Role.

Fetchmail retrieves mail from a remote server and injects it into the local mailer, which then handles it as if it were delivered directly to that host via normal means. Thus, procmail is invoked if it would have normally been invoked, and it's rules are processed as they normally would - procmail has no inherent knowledge of the formail process.

---
 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(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail

<Prev in Thread] Current Thread [Next in Thread>
  • Need Help!!, Rizwan
    • Re: Need Help!!, Professional Software Engineering <=