(cc'd by request)
At 11:06 AM 2/4/98 -0800, Clint Olsen wrote:
I thought that by using the EXITCODE, I would be assured that the email
would be *rejected* from ws1.TorahLink.com, but in fact Sendmail 8.8.7
attempts to deliver the "user unknown" to netcom.com, which is obviously
wrong.
Sendmail accepts the message, then passes it on to Procmail, either as the
local delivery agent, or via a .forward file (depending on your system's
configration). Procmail says "gee, gotta lie about not being here" and
rejects the message, when is sent back into the spool, and delivered
according to who it appeared to come from.
Had SENDMAIL determined the user didn't exist (password file / aliases /
virtusertable.txt), then it would have rejected the message right when the
remote was doing SMTP RCPT. But the user WAS valid, and so it accepted it.
Another scenario is when you have a mail secondary, and your primary (where
the user account and procmail are) is down. Some system goes to deliver
mail to you, and resolves to your secondary -- which simply holds mail for
your primary -- it hasn't a clue which user is valid and which isn't.
Well, the (E)HELO (the system sending your primary the message) takes place
during the SMTP session, the message is coming from your secondary - not
from the original sender. At THAT point, if the user didn't exist, I
believe sendmail would be issuing an unknown user error to the secondary,
which in turn should mail that message back to who it thinks is the sender
(I can't check my Bat book from where I'm at - any sendmail pros are
welcome to elaborate).
Is there any way at all to get around this (force the rejection at delivery
time)? Better yet, is there some sort of check to make sure that the
Received domain reasonably matches the From: domain?
You'd need to have a ruleset in your SMTP Daemon (generally Sendmail) to
check domains (which WILL fail on many valid messages, BTW) and reject it
WHILE the SMTP delivery session (actually, the negotiation) is in progress.
By the time Procmail has the message, you've completely accepted the
message, and any rejection you might hope to do is bouncing the mail - to
the apparent sender.
Such is the problem with forged mail.
I wouldn't suggest this tactic for fighting spam anyway - so much of it is
forged, and any bounce you send out simply uses up system resources on your
machine and those on the system that was spoofed. Spammers don't REMOVE
addresses from their lists (they want the lists to look as big as possible
when they go to sell it to someone else) -- dome have even taken to
GENERATING addresses at domains and sending messages to them with the
assumption that somebody will probably have an account by that name ("bill@
joe@ dave@ ...").
Use procmail to trashbin (or otherwise file) all the junk and then manually
take action on those which get through.
My .02, adjusted for inflation.
---
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