* Henry Ramos <hramos(_at_)opalgroup(_dot_)net> [2004-08-10 16:10]:
Hi All,
Apparently, I am noticing a new reoccurring problem with certain
email messages. Every now and then when checking mail with MS
Outlook Express, the email will get stuck on a message saying
"Receiving message 107 or 298" When I check message 107 from the
Linux system, I find that the messages ends with the characters ^@
sometimes there is more than one in a series such as ^(_at_)^@^(_at_)^@ etc.
I'd like to filter the messages that contain this string and just
dump them complete from the system (/dev/null). Is there anyway to
filter the body of the message to automatically remove the email if
it contains that string of text.
Assuming procmail filters your mail before you retrieve it, you should
filter the mail through spamassassin first in case ^@ gives it a high
enough score that you don't need to look for it specifically. Then
have the spam quarentined such that your Outlook MTA doesn't download
it.
If spamassassin doesn't care about ^@ codes, then you can follow SA
with a recipe like this:
:0 B:
* ^@
morespam
Since you have not received legit mail with this character, why would
you want to strip out the ^(_at_)? Use that flag to your advantage, and
quarentine those messages. Review them later with pine instead of OE
(or whatever MUA exists on the system running procmail).
Another approach would be to ditch OE and get another MTA that will
automatically refuse to download corrupt mail.
Also, if anyone has had the same problem, is this something new that
the spammers are doing to screw with normal email life... It
appears to only happen in junk email, I haven't noticed it in
anything legit.
I may be having this issue unwittingly. Fetchmail has been rejecting
much of my inbound mail, refusing to deliver it because it's corrupt
in some way.
Here is a portion of my procmailrc file, maybe there is something
wrong in there that causes email to put that funky stuff (^@) at the
end of the emails.
VIRTUALHOME=`/home/vpopmail/bin/vuserinfo -d $EXT(_at_)$HOST`
I'm not sure what that does.
MAILDIR=$VIRTUALHOME/Maildir
LOGFILE=/var/log/procmail.log
:0fw
* ^Subject:."Re: Your software"
/dev/null
Your fw switches are useless, because you're not filtering them, and
there's no need to wait for anything. It's quite risky to route
messages to /dev/null, especially based on such a general condition.
You are certain to lose legit messages.
I have the same comments for the two recipes that follow that.
:0fw
* < 15000
| /usr/bin/spamc
Again, 'fw' is useless here.
:0:
* ^Subject:.[SPAM]
$MAILDIR
Why would you deliver spam to your default inbox?
:0
*
$MAILDIR
This recipe makes the previous one useless.
____________________________________________________________
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