Sun 98-02-08 "Administrator - Henry Smith Jr. " <hensj(_at_)ihs2000(_dot_)com>
list.procmail
| What I would like to do is include a recipe that would check to see
| if the incoming mail includes a valid return address.
We have no way of knowing if the whole address is valid.
We only can validate the site with nslookup, that's the closest we get.
Get pm-code.shar [ See X-info header ] and use this
# RC caches the nslookups, so recipe will be faster the more
# you use it.
#
RC_NSLOOKUP = $PMSRC/pm-janslookup.rc
RC_EMAIL = $PMSRC/pm-jaaddr.rc # will break email to parts
:0
* condition to send reply (detected possible spam somewhere along the line)
{
# Where are we about to send the message ...
INPUT = `formail -rt -xTo:`
INCLUDERC = $RC_EMAIL
INPUT = $SITE # exploded by $RC_EMAIL
INCLUDERC = $RC_NSLOOKUP # verify it
:0 # nslookup for $SITE failed
* ERROR ?? yes
{
# we can't generate reply to this address...
:0 h
header.mbox
}
}
| how heavy would this be on the system? Single account verses a system wide
| recipe?
This is what someone commented...
18.2 My ISP has systemwide procmailrc; is this good idea? [pm-tips.txt]
[eli] I, for one, do not like my ISPs to put stuff in
/etc/procmailrc. There is precious little I will gain from that and
plenty of opportunity for them to make mistakes I would not have. At
one ISP I know people got upset at some sendmail level filtering of
email. One of those upset is a habitual complain-to-spammer-ISP
person. He did not want problems seeming to go away if they were
really there. Another guy just didn't trust the filtering.
Writing a shell script that will give the user a .procmailrc which
includercs a system wide shared procmailrc is the best way to do it.
This forces the filtering to be "opt-in".
| I would also like the all the
| header info from any bogus mail to be logged into it's own seperate file.
See the recipe.
Cheers!
jari