At 21:10 2006-10-02 +0100, Steve A wrote:
Professional Software Engineering wrote:
If they're valid email addresses at your domain, this is referred to
as "joe-jobbing". Otherwise, it's simple forgery.
They're valid addresses at my domain because I accept them because I
haven't yet compiled a list of all the addresses I've used for myself
(eg. procmail(_at_)mydomain(_dot_)tld). They're random (often rude) words
used to
make the user part of the address.
IOW, you're accepting mail at your domain with a wildcard. This isn't
wise, since spammers don't have to have a valid email address in order to
smack you.
If you have your email saved, grep it all for addresses:
grep "@rowyerboat\.com" | sed -e "s/^\(.*[
<]\)\([-a-z0-9_(_dot_)+]*(_at_)rowyerboat\(_dot_)com\)\(.*\)$/\2/i" | sort |
uniq
(paren escapes are present because my shell needs them). This could stand
to be improved, but should serve well enough as a start point for you.
Sort though the list and delete the bogus ones, then bring the rest into
your MTA config (for sendmail, you'd be replacing the wildcard in
virtusertable with the list). tweaking the above sed replacement text from:
\2
to
\2 yourlocaladdr
would put it all in the syntax that sendmail expects for virtuserable,
which would reduce your edit time significantly.
Dealing with this is best handled at the MTA, rather than receiving
all the junk.
I don't have control at SMTP level, only what procmail can do for me.
Then get your user address list and get it to the system admin. That
should reduce your cruft volume significantly.
I have big issues with bouncing messages of this nature, because it only
adds to the pleathora of junk already in circulation, and I don't want
to dump my problem onto someone else.
bouncing a URL _during_ SMTP would involve no more network traffic than is
already being generated if you end up receiving the messages
instead. Figure, if you were getting _delivery_ bounces, it'd be one thing
(generally only for recipients who were at mailhosts not available when the
spam was originally delivered, and thus it relayed through backup MX's that
couldn't validate users), but you seem to be complaining about automated
systems SENDING YOU SPAM NOTICES for a message you didn't send. If you ask
around here, you'll find that among the procmail crowd, sending notices
about spam AFTER the SMTP stage is generally frowned upon. You, on the
other hand, would be BOUNCING (refusing) delivery of the report, and
providing a URL to a page reporting that the crap didn't originate from you
in the first place (assuming of course that it wasn't actually relayed
through your mailhost...).
In the course of writing this email I've solved the problem, so here's
the result. If anyone can think of something I've missed, or need to
watch out for, please chip in.
:0
* ^From:[ \t]*\/.*
Er, you don't think for a minute that \t means "tab" do you? Procmail
won't parse it that way. Insert a hard tab.
Why not use the ENVELOPE sender (the From line - no header colon) ?
* $? echo \"$MATCH\" | grep -i -f $LIST
testbox
If you're delivering to a mailbox, you should have a lockfile flag on the
flags line.
You also don't need the echo, a -x might be good to add, and fgrep should
give you somewhat better performance:
* $? fgrep -i "$MATCH" -x $LIST
---
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 homepage: http://www.procmail.org/
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail