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