At 20:47 2002-06-12 -0500, Nick Gray did say:
said. Since the M4 file referred to sendmail 8.8.9 and I am using 8.12.3,
I guessed that one of the rules (not all) below did the same thing in the
newer version of sendmail.
How you invoke procmail as LDA has remain pretty much unchanged for a very
long time. Certainly the LDA config predates 8.8.9.
As for the .mc file, since the commands listed are M4 macros, I didn't
think it would be necessary to say that it was the sendmail.mc file
More the point was that it isn't the file that sendmail reads - it's a file
which it processed via macros into a file which sendmail reads. The
resulting file could be significantly different between sendmail
releases. Also, because it's a file which GENERATES another file, there's
no guarantee that what is in that file has any bearing on the actual
configuration in use - people have been known to make changes to files and
not propogate them to where they need to be (such as /etc/mail/sendmail.cf).
Use of M4 files is encouraged - it helps to maintain configuration
stability across NTA updates even when the underlying macros
change. Managing a .cf file (esp .cf files across MANY hosts) is a PITA.
The intent of the script, since perhaps, it wasn't obvious was to toss a
piece of mail that met a certain criteria and indicate why the mail was
tossed to a log file. The piece of mail that matches shouldn't be delivered.
That was clear -- my point was that if you add the 'i' flag, the process of
piping it to the echo which adds to the specific log will result in the
message actually being "delivered" by procmail, and thus you don't need to
have a following recipe to expressly deliver it to /dev/null.
My understanding is that only one action line can follow the condition,
Or conditions plural, or no conditions at all.
hence the two conditions that match everything inside of the actual
conditional. One does the logging and the other causes the mail to be tossed.
Add the 'i' flag, and the logging line will toss it. The only reason it
doesn't already is that procmail views that action as a _FAILURE_ because
the message wasn't fully read by the piped command (echo doesn't read
stdin). Turn on verbose logging and take a look.
Isn't that correct. I would like to see a more efficient way of doing this.
:0i:
| echo "whatever" >> logfile
(yea, I neglected in my original post to mention that since you're
outputting to a logfile, the recipe really should be locked).
Once delivered, it doesn't need to be thrown away. The issue is that the
pipe to echo doesn't READ the message, and therefore procmail sees it as
a delivery failure. Add the 'i' flag (see 'man procmailrc') to the
logging line, and you can eliminate the discard delivery.
I don't understand what the i option is going to do here, explain.
Please read 'man procmailrc'. Refer also to 'man procmailex', where the
flag is used when invoking a mkdir command (though in that case, it's
accompanied by a 'c', which means it's operating on a copy of the message
anyway - but one which it is discarding).
I emit elements to my regular procmail log, and have a simple script
invoked by crontab that grabs the ^SPAM: lines and emails them.
I wanted to avoid parsing a file.
Difficulty on a 0-10 scale: 1
grep ^SPAM logfile
The criteria was single line entry delimited by colons. This is why I
didn't use the standard logging
You may have some specific syntax need. Whatever - it's your boat, pilot
it as you will. I was suggesting how I do it: right into the procmail log,
which is where the dispositions of ALL my messages get tossed. Further, my
procmail log includes info on specifics of WHY the message was tagged as
spam, emitted by LOG="message" constructs.
Refer to the Sendmail Bat book, 19.6.32. LOCAL_RULE_0 is not synonymous
with LDA.
Even though that is what I probably said, it is not what I meant. I meant
that incoming traffic is being caught by procmail due to one of the rules
in the M4 file.
Ah, you said NOTHING of INCOMING. Only the incoming traffic which results
in a local delivery to a user account -- not things which deliver via an
alias to a forward account, or to a program or file -- will be processed by
the LDA. Outgoing mail - anything LEAVING your server - isn't subject to
LDA filtering. If that defines the dataset of what you want filtered, then
yes, the LDA is sufficient for what you're doing. It however IS NOT the
same as filtering it at LOCAL_RULESET_0.
So unlike adding regexs to sendmail, your saying I can test by sending a
user mail that will go out through sendmail, but will be caught by
procmail on the way in.
(i.e mailing out as local nagray to nagray(_at_)austin(_dot_)rr(_dot_)com and having
fetchmail pull down mail for local nagray from nagray(_at_)austin(_dot_)rrr(_dot_)com, If I
was filtering the out the word "sex" I should be able to send but not recieve)
Bottom line: LDA only effects messages delivered to local users. It isn't
invoked for messages leaving your system. It would leave without event,
and then be filtered when being delivered to the local user account, yes.
That's cool.
"cool" as in "wow", or "cool" as in "I'm totally okay with that limitation"?
/etc/procmailrcs is not used by my version.
Which version is that, and why is this so?
---
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