Philip Guenther wrote:
Ralph Freshour <rfresh(_at_)mail(_dot_)idt(_dot_)net> writes:
When incoming mail arrives on my server, I need to check a text file to
see if the incoming mail is addressed to a valid userr. I need to:
1. Parse the username out of the To: field.
For example, To: Joe Smith <joe(_at_)domain(_dot_)com>
I need to parse out "joe" because the
file of authorized users looks like this:
mary
henry
joe
bill
I need to find "joe" in that list file.
The authorized users file is called "users.list"
2. If "joe" is not found in the file, send to /dev/null
else contine to the next recipe.
a) Are the "authorized users" a subset of the user accounts (logins) on
the system? If not, forget procmail for now and start reading
up on sendmail, especially LUSER_RELAY.
No. My customers use my company's domain name with their own username.
They do not log in to anything. I just process and if needed, forward
their email to another mail address. I would prefer to just keep track
of authorized users from *my* company point of view (not from a login
server point of view - they don't log in at all). I maintain a file of
usernames and I simply want to check incoming email to make sure the
mail I process if for an authorized customer of mine.
b) You're not going to send a bounce message back to the original site
saying "sorry, so-and-so is not authorized to receive email"???
That's rude.
I don't mean to be rude - I certainly can bounce the msg back, but I was
thinking what with all of the email traffic on the 'net these days it
might be better to not 'clog' the system. You are the 2nd person that
has mentioned it would be better to bounce back the msg - so I will do
that!
c) Why don't you just add to sendmail's ruleset 5 a lookup into a text
file database, such that if the user didn't have an entry it
returned a call to the error mailer? Something like (untested
code alert!):
R$+ $: < > $1
R< > $+ + $* $: < @ > < $( auth $1 $: <> $) > $1 + $2
R< > $+ $: < @ > < $( auth $1 $: <> $) > $1 look up user
R< @ > < <> > $* $#error $: NOPERM or whatever
R< @ > < $* > $* $: $2 They're okay
Then a suitable line defining the auth map and you're off and running.
I know procmail can do this and I'd prefer to just stick to that. I'm
struggling as it is using procmail so I'd prefer not to dive into
sendMail at this point - but maybe in the future. I'd like to get this
working under procmail if I can.
As a general rule, I believe that if you're trying to reject and/or
redirect incoming email for multiple local or pseudo-local destination
addresses, then you should be using sendmail to do the work, not
procmail. As a Mail Delivery Agent, procmail does not have all the
information needed to do the above. Furthermore, it lacks the database
lookup machinery that makes the above efficient. Procmail may be
easier to understand then sendmail, but that doesn't mean it's right
for every task you can throw at it. To quote Archimedes, "Give me a
place to stand and I'll move the world." Sendmail is standing in that
place in the email universe, and procmail is not about to dethrone it.
Funny you mention that Philip, I just ordered the sendMail book (4 days
ago) from my local bookstore - I am anxious to read up on it!
If I seem to be repetitious in my hitting of this nail, that's because
I've watched people try to do virtual domains inside procmail (which is
only slightly different from what you describe above) for the last 4
years at least, and I have yet to head an unqualified success story.
People, including myself, have talked about getting sendmail to pass
the required info into procmail via a 'X-Envelope-Recipient:" header or
something similar, but I have never seen a working sendmail config
which did so. I even gave it a shot myself and found that I couldn't
get it to work. Now we have the "virtusertable" feature in the
sendmail m4 configs that does the entire thing in sendmail is 5 lines.
I'm *not* doing virtual domains, I'm only using aliasis:
joe(_at_)mydomain(_dot_)com
mary(_at_)mydomain(_dot_)com
etc
etc
but the domain name is the same for all customers - all I need to do is
have procmail process the mail. What this means for me is to first
check my users.list file to make sure they are in it, then check their
junkmail file to see if the incoming mail is from someone they don't
want to get mail from in which case it's gets trashed or else I simply
forward the mail on to an adress where they actually read their mail.
Thanks for your comments...
--Ralph