procmail
[Top] [All Lists]

Re: Recipe woes

2003-05-28 16:14:29
On Wed, 28 May 2003, Professional Software Engineering wrote:

At 12:35 2003-05-28 -0500, listuser(_at_)numbnuts(_dot_)net did say:
The goal of this script is to munge my users' information from spam and
forward it on to the FTC and NANAS as well as archive the spam locally.

Well, if you're forwarding it, those particular sites aren't likely to hand 
it to the spammers.

I'm not worried about the FTC or a DNSBL maintainer displaying unmunged 
mail to the masses.  My concern is NANAS (news.admin.net-abuse.sightings 
in case someone doesn't know), where people post spam for others to see 
and compare notes on.  Google Groups is a handy way to check to see if a 
domain or IP has a spamming history.  It's also an extremely easy way for 
spammers to harvest more addresses for spamming.  Then again, if my spam 
filtering is doing it's job then perhaps I shouldn't care if I post my 
users' full addresses.  I could always substitute that particular domain 
for one of my own which I use for spamtraps.  Then the spammers would be 
harvesting more addresses for use on my own spamtrap.  I like that idea.  
:)  I think I'll forget the userid munging and switch to domain 
substitution.

I'm trying to munge all instances of my users addresses from both the
headers and the body.

Keep in mind that spammers not infrequently use encoded URLs (esp for 
embedded graphics in HTML email), which ties any given referral to an 
address in their database.  Thus, if you're afraid that the FTC or whomever 
is going to forward your message along to the spammer as evidence that they 
sent spam, you're going to need to contend with coded URLs that you don't 
know the meaning of.

Yeah, I'd thought about that some too.  I'm not terribly worried about it.  
I'd hoped that my sed munging might catch a spammer that didn't encoded 
URLs in the body.  I decided to not be too concerned with the others 
though.  combat.uxn.com links to a nice decoder.

  That part is relatively easy.  What I'm having
trouble on is the quoting of the original message.  I need to quote the
full headers and body of the original spam in the body of the new message
(forward).

:0
| ( cat $AUTOREPLY/this-is-spam.txt - | \
         formail -I"Subject: SPAM REPORT" \
         -I"X-Loop: your-reporting-address(_at_)yourdomain(_dot_)tld" \
         -I"From: your-reporting-address(_at_)yourdomain(_dot_)tld" ) | \
         $SENDMAIL -f your-reporting-address(_at_)yourdomain(_dot_)tld 
ftcaddr nanasaddr

Excellent!  This seems to be working just fine.  I had to comment out the 
part of the recipe that called "$SED -e H -e '$ G'" because it was putting 
a second copy of the headers in the message.  I guess that's what it was 
supposed to do (now I know).

The only real problem I see here is how to handle encoded mail.  The piece 
of spam I bounced to my spamtrap was apparently encoded.  After the quoted 
headers was numerous lines of gibberish.  Pine apparently decoded it for 
me and showed me the HTML so I didn't realize it was encoded (in what I 
don't really know).  Procmail quoted the encoded part and that what I was 
seeing.  I saw this when I viewed the actual mail spool on the sending 
mail.  Is there a way for Procmail to decode that junk first before 
quoting it?  This is probably a horrible description of what I'm seeing.  
if you need a better descrition, just ask.

  I haven't been able to figure that out.  I believe the munging
is working.  Here's the state my recipe is currently in:

You should head directly to the URL in my .sig, then follow the links there 
to information about my "sandbox", which is a setup which allows you to 
test recipes outside of your live mail stream, and (if you set up your 
recipes in a structured fashion), allows you to take a recipe from test to 
implementation without making any further changes to it.  For instance, the 
sandbox redefines $SENDMAIL, so that when you send something to $SENDMAIL 
or use ! to forward, the message isn't actually sent to sendmail, but is 
instead dumped into a file which you can examine.

This would greatly simplify your debugging process.

Yes it would.  Many thanks!

Justin


_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail

<Prev in Thread] Current Thread [Next in Thread>