Re: Need Help!!

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