|
Re: Few misc questions.
2004-02-05 23:23:13
At 19:55 2004-02-05 -0500, Robert Krueger wrote:
1. All my mail that isn't tagged by SA and deposited in a special file
is sent to a maildir/ type folder. Because my virus stuff plus the SA
stuff are in a regular MH style file, I used the :0 : format telling
MH "files" are separate files. I think perhaps you mean mbox
file. Procmail basically supports storing messages in FOUR distinct ways,
as outlined in a message I posted yesterday: mbox, two file naming
conventions for MH, and maildir (with new/ old/ tmp/ subdirs). Excepting
mbox, all the other formats are one-message-per-file, and therefore do not
require locking.
procmail to use a lockfile on these files only. I assume this is
proper, as I see no need to use maildir/ format style directories to
deposit spam and viruses. While i go to the trouble of scanning these
files using "less" to make sure I'm not getting good mail deposited
here, I have to believe there's an easier way. Isn't there some mail
utility that can scan all this mail in one of these files ( one at a
time, all, whatever)
Uh, I'm unclear on how you're having a difficulty in reviewing them.
and lay it out neatly so I can see what type of mail is in there? ( I did
try "mailstat", it's kind of a "busy" display)
mailstat works best with a procmail logfile which is is logabstract
only. Verbosity and manually-emitted notes make mailstat pretty
noisy. You could filter a logfile before passing it into mailstat though -
eliminate lines not part of the logabstract:
egrep ^"(From | Subject:| Folder:)" log | mailstat
Replace 'mailstat' with 'less' and you can just page through the simplified
logfile.
2. Because I subscribe to three maillists, which can involve a lot of
mail,
Because I subscribe to several maillists and admin several more, I get a
*LOT* of email. I average over 700 a day. Then there's the frantic days...
The first block says (I think...) "If this email is NOT one of these
three mailing lists, then execute the code between the braces {}.
If you're going to use scoring, then use maximal score on any one of the
conditions (I presume they are actual checks of specific headers - the
rewritten summarization isn't the best way to seek explanation of
code). Why? because as written, it certainly appears that unless it's
*ALL* of the lists simultaniously (that is if it isn't a procmail AND
postfix AND evolution message, and I think you'll agree that's unlikely)
then you'll have a nonzero score and the message conditions will be
considered true.
Either lose the scoring SCORING aspect, and just invert the conditions (all
conditions need to evaluate TRUE, that is NOT the lists):
* ! procmaillistcondition
* ! postfixlistcondition
* ! evolutionslistcondition
{
# do stuff
}
or, use a NEGATIVE maximal value ('minus infinity', which for procmail is
anything larger than negative 2^31) in your scoring, but DO NOT invert the
list check (thus, if the list condition is met, the scored conditions stop
being checked and it skips the recipe). This is more efficient, since
condition evaluations stop as soon as any one of the conditions is found to
be true. Ordering the checks in order of list traffic levels allows you to
tweak the performance ever so slightly: if you receive 100 procmail
messages a day, five postfix messages, and one evolution message, you'd
want to order it so that the procmail list is checked first, since MOST
messages would match that condition and continue past this recipe right
away without wasting the (nominal, for sure) cycles on the other
checks. If you put evolution first, then the 100 procmail messages would
have to check that condition, fail it, and then check the procmail
condition and succeed on it. Minour optimization for sure, but in any
event, this is more efficient than the alternative above, which will check
all conditions for ALL messages.
* -9876543210^0 procmaillistcondition
* -9876543210^0 postfixlistcondition
* -9876543210^0 evolutionlistcondition
{
# do stuff
}
What's a fairly bulletproof way to snag mail from a mailing list?
I'm a little confused over the special variables that can be used just
for a mailing list, truth be told.
Check the procmail list archives for a recipe defining LISTNAME. Such
recipes (including one I posted not so long back) have been written to
generically identify a list message based on commonly-inserted
headers. owner-listname, X-Beenthere:, and certain list-RFC specific
headers can be checked for, and the listname discerned from them. So, I
run these filters up near the top of my procmailrc processing, and
subsequently, I can do:
:0
* ! LISTNAME ?? (procmail|postfix|evolution)
{
# do stuff
}
That condition is very literal - it isn't a vage pseudocode rewrite. I use
the same sort of thing to define additional "padding" for my spam filters
on some lists. Procmail for instance discusses viruses frequently, so it
needs a lot more padding. Other lists have a sufficient number of other
characteristics (such as removing Received: lines from before the list
handling, which interferes with detecting forged freemail messages), that
some padding is appropriate.
3. Last question. These spammers are getting sneakier. They used to
use just .exe attachments, now, among others, they use my old reliable
..zip extension as well.
That's not spam per-se, it's virus. Spammers _generally_ want to send you
advertising, though in some cases, they've used malware to obtain address
lists or produce zombie SMTP servers, such messages still fall under the
general category of virus.
So virussnag.rc can snag these also, no problem, but I thought it would be
wiser to use a conditional statement somehow that said, basically, "Check
this list, and if this file with the .zip attachment is from anyone on
this list, then let it in".
It's called a Greenlist - if you really want to implement one, scan the
archives for that term.
However, I'd *STRONGLY* caution against this for virus scanning - the whole
basis of email based viruses for the past three years has been to use email
addresses culled from saved mail and addressbooks and send messages FORGED
to be from those addresses to other addresses culled from the same
sources. And prior to this technique, viruses commonly simply spread From:
the infected user to the addresses which could be found on their
system. Either way, MANY of the viruses you get will be from addresses
which you recognise. Moreso for people with small contact lists who do not
participate on discussion lists, but you'll still get viruses from
addresses you recognize, which were not really sent by those parties.
It's fine to use a greenlist to bypass _spam_ checking, but if you're doing
virus checking, you shouldn't have ANY greenlist to bypass that.
Most of my zipped up stuff comes from business associates, so I do want
to receive these mails,
Then don't simply _discard_ zips - look for signatures associated with
certain viruses. Or, request that your business associates send ZIPs in
messages which they've PGP signed. Problem solved.
I myself have been a longtime registered ZIP user (from the OLD days - I've
used Phil Katz's software since PKARC). If you're a registered ZIP user,
you can apply for an authentication code -- PKZIP can embed a code into a
zipfile that authenticates the files which YOU added. So, even if PGP
isn't an option (sucks to be you if it isn't), authenticated ZIP files can
be. I'm unaware of any support for authentication in the open source ports
of ZIP though, but if you use the actual PKWare versions of the program,
you've got access to the feature. It is popular for software authors,
since you could validate your own archives as not having been tampered with.
Similarly, encrypting the zipfiles is another way to circumvent virus ZIPs
- if everyone on a development team encrypts their ZIPs, then only the
other members of that team (those with the password) can extract it. A
_virus_ that goes around with a password would be useless since nobody
would know the password and thus wouldn't be able to extract the file.
Now, watch, some virus writer will start encrypting ZIPfiles and the virus
will send out TWO messages - one with an "I'm sending you a file, it's
encrypted with the password 'blah'", and the other with the attached ZIP....
Well, PGP remains my choice for validating legitimate message content, but
I still transfer most stuff (since I'm the one sending stuff to clients)
via client-specific FTP accounts and authenticated HTTP downloads, so
program files aren't being sent around as attachments anyhow.
---
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(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail
|
|