On 17 Jan, Lars Hecking wrote:
|
| _LART_
|
| Can someone please unsubscribe pcastillo(_at_)ggcargo(_dot_)com from this
list?
| Thanks.
|
| [...]
No disagreement with the appropriateness of the LART nor the request.
In the meantime, this is something I put together a couple weeks ago
for a couple of other lists with the same crap. When the first one of
these came to the procmail list a week or so ago from ggcargo.com, I
added them to the data files. I will warrant *nothing* beyond the fact
that it worked *this* *one* time. I didn't see today's message.
# N.B. $PMDIR needs to be set appropriately or removed. Also, the
# variable assignments for .data.* files aren't necessary, but they
# help with how I manage rcfiles. The variable assignments are at
# the top (or in another file all together) and not necessarily in
# close proximity to the recipes, and I just don't like hard-coded
# paths. Lastly, some of the grep options are likely GNU specific.
VirusAlertMorons = $PMDIR/.data.virusalert.morons
VirusId = $PMDIR/.data.virusalert.id
VirusMore = $PMDIR/.data.virusalert.more
:0
* < 16384
* ? formail -cz -xReceived: |fgrep -qwf $VirusAlertMorons
* B ?? ? grep -qwEf $VirusId
* B ?? ? grep -qwEf $VirusMore
{
LOGABSTRACT=no
:0:
| gzip -c >>$PMDIR/JUNK.dbg.gz
}
# .data.virusalert.morons
alltrom.ro
bewegungsmelder.de
ggcargo.com
gliatech.com
gehag-dsk.de
humandata.se
manic-gmbh.de
mummert.de
pbs.dk
# .data.virusalert.id
^ScanMail
^Ereignisinformation:-
^Incident Information:-
^Antigen
^\**SISTEMA DE PROTECCION DE VIRUS
# .data.virusalert.more
WARNING
WARNUNG
Sender
Originator
Urheber
Recipient
Empfänger
Engine/Pattern
attachment
empfangene
[Vv]irus
Action
infected
infiziert
daños
My nemesis - MailMarshal - is not included above because I have a
special axe to grind (and recipe) for them.
The idea is to force enough matches to prevent (or at least
significantly minimize) false positives. A message must first match a
list of domains from where this moronic behavior has been previously
observed. Then the body must contain one specific string, hopefully
unique enough to be a fingerprint of the brain-dead software (or
implementation). Then it must match once more from a list of more
generic strings. The first string match might be sufficient, but the
second adds some protection to ease my anally cautious mind. For that
matter, someone willing to throw caution to the wind might do this
without the domain match. At any rate, using formail to extract
Received: headers is probably unnecessary (i.e. scanning for the domain
against all headers would be fine), but it's just a work in progress.
Clearly, this wasn't designed to be resource friendly, especially for
such an infrequent circumstance. But they're my own systems and I can do
what I want. ;-)
Eventually I'll replace the appending to JUNK.dbg.gz with delivery to
/dev/null, but it hasn't been in use long enough for me to be
comfortable with that.
--
Reply to list please, or append "6" to "procmail" in address if you must.
Spammers' unrelenting address harvesting forces me to this...reluctantly.
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail