[Raw Msg Headers][Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: message tagging...



Hi,

as architectural responsible (should I say culprit?) for the 
zmailer+mailscanner combo, I'm not at all proud of what we did... It just 
got the job done... losing lots of zmailer's performance in there...

The point is, I'm not a great C coder and zmailer's code is well beyond 
my knowledge... in fact, I don't even speak zmsh... as I could read & 
understand MailScanner's Perl easily, I went that way

FWIW, I'd be perfectly happy if someone found a nice, efficient, way to 
tag the message based on some program's (e.g. SpamAssassin, but could be 
any other one) output.

For AntiVirus, we didn't test it, but Eugene's ZMScanner has a clamav 
plugin that would allow you to reject mails with virus at the door, 
during smptserver dialog, which is nice since "legitimate" virus senders 
would get feedback _and_ you won't end up with zillions of rejections to 
unexistant addresses in your output queue.

I agree that AS & AV are quite a different thing... with AV it is mostly 
a black/white question, so I'm quite comfortable rejecting/erasing... 
with spam and possible false-positives, I don't like the idea of 
rejecting/erasing.

just my 2c.

El 23 Jan 2004 a las 19:44, Carlos G Mendioroz escribió:

> May be virus checking and SPAM control do need different mechanisms.
> Zmailer builds heavely on the "do not touch the message" principle,
> thus being as easy as possible on I/O. I like that, so I don't want
> to change the message file (queue). I would not do that at process(),
> but rather at rfc822().
> 
> Changing headers is taken care of, and I think it's fairly easy to do.
> The tagging (adding headers) is almost trivial. And is all what I need
> for SPAM control at the MTA. Changing the mail message as a virus 
> scanner may want to is outside this scope...
> 
> Actually, I'd better quarentine (sp ?) or bounce the message than (try 
> to) clean it, but this is just my current not much thought about point 
> of view :-)
> 
> Jeff Warnica wrote:
> 
> > 
> > This is the current theory at my site as well. At the SMTP level, block 
> > mail
> > from a specific list of sites, but do content analysis at a later step.
> > 
> > We have been using MailScanner for a while now, and it works fairly 
> > well, but
> > there are some issues with it. Primaraly is how it deals with the queue 
> > dirs...
> > The quick version is that it is stupid, and even if it was smart, 
> > ZMailer keeps
> > good track of its queues, so it is a duplication of effort.
> > 
> > Personaly, I have toyed with the idea of developing such a scanner, and 
> > after
> > some investigation, I think I found the best place to put it would be in 
> > the
> > cf/process.cf script  (around line 30, just above the case statemnt). I put
> > together a proof of concept script. It is at a state where it doesnt do 
> > much
> > beyond passing the message to spamassassin and rewriting the header. I was
> > supposed to do some thinking on how to do virus scanning as well, but 
> > never got
> > around to it. And I have no idea how solid it is, re: lock files, rewriting
> > queue files on the fly, etc.
> > 
> > MailScanner, for instance, cleans virus infected attachements, so to be 
> > feature
> > compleate against it, some new queue file rewriting methods would be 
> > necessary.
> > OTOH, ZMailer already does some header alterations; for simple spam 
> > taging, it
> > may make sence to somehow get ZMailer to do it.
> > 
> > Anyway, if you want my script to look at and ponder, Ill send it out to the
> > list..
> > 
> > Quoting Carlos G Mendioroz <tron@huapi.ba.ar>:
> > 
> >> It's been talked about several times about how to integrate spam/virus
> >> message handling into zmailer. Current approach AFAIK is to let a
> >> content-filter (possibly) reject a message at SMTP reception.
> >>
> >> I'm more keen to include into router a function to tag a message based
> >> on (possibly external program sourced) zsh scripted logic.
> >>
> >> What I'm thinking of is to:
> >> -have queue message file name available at zsh context
> >> (possibly already there) to be able to spawn an external program
> >> and get its output.
> >> -add a tag() function that would add a new header to the message.
> >>
> >> That would enable me to run spambayes on the original message w/o
> >> any message rewriting. Tagged message would then be acted upon
> >> usually by UAs for deletion or whatever at users will.
> >>
> >> Comments ?
> >>
> > 
> > 
> 
> -- 
> Carlos G Mendioroz  <tron@huapi.ba.ar>  LW7 EQI  Argentina
> 
> -
> To unsubscribe from this list: send the line "unsubscribe zmailer" in
> the body of a message to majordomo@nic.funet.fi


--
Mariano Absatz
El Baby
----------------------------------------------------------
The primary purpose of the DATA statement is to give names to
constants; instead of referring to pi as 3.141592653589793 at
every appearance, the variable pi can be given that value with
a DATA statementand used instead of the longer form of the constant.
This alsosimplifies modifying the program, should the value of pi
change.
                         -- FORTRAN manual for Xerox computers


-
To unsubscribe from this list: send the line "unsubscribe zmailer" in
the body of a message to majordomo@nic.funet.fi