Mary Smith wrote:
Suppose that I didn't understand my sysadmin correctly when
he seemed to tell me back in June that we aren't running
sendmail at all, but are running procmail, so if procmail
From what you write below, it seems your ISP really is running
sendmail. I mean, if there's a sendmail.cf file there and all...
exits with error code then the message hasn't been received
by our ISP at all? Suppose what he really meant to convey is
that procmail runs in realtime underneath sendmail or other
SMTP listener while the SMTP connection is still, before the
SMTP listener acknowledges successful transmission of the
message, so if it errors out then the SMTP connection is
closed either without any ACK at all or with explicit NAK of
some kind of error? Then maybe the following is relevant:
...
Well, I just tried an experiment. Here's what seems to happen.
Sendmail accepts the entire message, placing it in the queue. Then it
passes the queued message to the LDA (procmail in your case). If you
give it EX_TEMPFAIL or EX_NOUSER then sendmail will generate (!) a
message to the presumed sender (probably forged) of the message saying
that something bad happened.
...
{{grep '^Mlocal' /etc/sendmail.cf ## does it say "procmail"? )}}
On my ISP it says:
Mlocal, P=/usr/local/bin/procmail, F=lsDFMAw5:/|@qSPfhn9, S=10/30,
R=20/40,
Does that look correct? Those flags etc. are inscrutable to me, a mere user.
Looks to me like they're running sendmail.
{{http://www.procmail.org/jari/pm-tips-body.html#technical_matters}}
{{{the code that you will be using mostly is EX_NOUSER or
EX_NOPERM. It tells to the sender of UBE to "piss off and
delete me from your list; I'm not here"}}}
Yeah, but does anybody actually believe this would EVER
cause my address to actually be deleted from the list of six
million e-mail addresses that is re-sold to every new
spammer and to thousands of suckers who receive the SIX
MIILLION ADDRESSES advertisement as spam?? I'd rather have
the mailer on the spam-condoning ISP to be tied up three to
five days repeatedly trying to deliver e-mail to each of
those six million addresses, every one of which has a spam
filter which says EXITCODE=75 "temporary problem, try again
later".
Unfortunately what really will happen is that "temporary problem"
messages will go flying howevermany accounts to the forged
return-address's ISP.
{{{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.}}}
What happens if SMTP RCPT was accepted, and THEN something
went wrong and sendmail or the whole system or the whole
InterNet crashed and the message BODY couldn't be totally
received? (I'm not talking about spam, I'm talking about
normal e-mail here.) Does the message just get lost, or is
there some kind of later acknowledgement in SMTP that says
the whole message was delivered successfully, so if that
later ack doesn't occur then even though SMTP RCPT was
successful the message is still retained at the sender's
host and re-tried later when the net is back up?
The latter. The sending MTA should not toss the message until he sees
250 blabla Message accepted for delivery
at end of message.
So if procmail does an ERRORCODE to indicate temporary
failure, won't that be seen by the sending host as something
going wrong after SMTP RCPT but before confirmation of full
message text delivered, hence retain original message and
re-try sending later?
To accomplish this, I think you need to terminate (with exitcode=67)
earlier -- during rule processing, not after the message is already in
queue. Say "man procmail" and search for "Mprocm" and read the
section there. I *think* that if you can decide what to do with the
mail during header processing, for example, sendmail might be able to
reject the message during transit rather than sucking it all into the
queue. Will your sysadmins let you insert stuff into sendmail.cf??
...
the user authorizes it. So spam simply sits on the server
until it expires. What I want is the same idea but back one
level. E-mail sits on the machine of the person who
originally sent it, until the destination machine gets
permission from the user to accept it. So my own ISP would
This will not really work. A spammer with half a brain will find an
open relay (there are tons of them around the world) and the spam will
sit on some clueless server in Korea or Greece rather than on the
spammer's system. So if you could get the reject-while-sendmail-
connection-is-open scheme to work, you'd be punishing clueless admins
in Korea or Greece, not the spammer.
...
--
Neither I nor my employer will accept any liability for any problems
or consequential loss caused by relying on this information. Sorry.
Collin Park Not a statement of my employer.
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail