You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Shane Williams <sh...@shanew.net> on 2015/03/13 22:41:33 UTC
Which milter do you prefer?
I've been reviewing the current landscape of anti-spam tools since I
haven't set up a new system in a while, and one place I'm wondering
what people are using is milters for spamassassin/spamc.
It seems like spamass-milter is the default go-to for most people, but
I'd really like one that can listen on an INET socket (and
spamass-milter doesn't as far as I can tell, but please correct me if
I'm wrong). Milter-spamc from SnertSoft looks promising, but it's not
free, and a bit more complicated. smtp-vilter also looks interesting,
but it does more than just SpamAssassin stuff, so might be overkill.
And I suspect there are a bunch more out there (though a lot of these
projects seem to have stalled or died over time).
What are your favorite (not spamass-milter) options for plugging
spamassassin into a milter?
--
Public key #7BBC68D9 at | Shane Williams
http://pgp.mit.edu/ | System Admin - UT CompSci
=----------------------------------+-------------------------------
All syllogisms contain three lines | shanew@shanew.net
Therefore this is not a syllogism | www.ischool.utexas.edu/~shanew
Re: Which milter do you prefer?
Posted by "David F. Skoll" <df...@roaringpenguin.com>.
On Fri, 13 Mar 2015 16:41:33 -0500 (CDT)
Shane Williams <sh...@shanew.net> wrote:
> What are your favorite (not spamass-milter) options for plugging
> spamassassin into a milter?
MIMEDefang because it gives you a whole filtering framework in Perl
in addition to integrating with SpamAssassin.
http://www.mimedefang.org/
Of course, I wrote it so I am very biased. :)
Regards,
David.
Re: Which milter do you prefer?
Posted by Lucio Chiappetti <lu...@lambrate.inaf.it>.
On Fri, 13 Mar 2015, Patrick Ben Koetter wrote:
> amavisd-new via amavisd-milter.
That what's we got since 2006. Since 2011 spamassassin is second choice
after graylisting (i.e. it rejects what graylisting let through)
Re: Which milter do you prefer?
Posted by Patrick Ben Koetter <p...@sys4.de>.
* Shane Williams <sh...@shanew.net>:
> What are your favorite (not spamass-milter) options for plugging
> spamassassin into a milter?
amavisd-new via amavisd-milter.
amavis because it allows to define actions for spam that go beyond 'HOLD'
or reject. And, if you want to do more than spam detection, amavis takes
you there as well.
p@rick
--
[*] sys4 AG
https://sys4.de, +49 (89) 30 90 46 64
Franziskanerstraße 15, 81669 München
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein
Re: Which milter do you prefer?
Posted by Bill Cole <sa...@billmail.scconsult.com>.
On 13 Mar 2015, at 17:41, Shane Williams wrote:
> I've been reviewing the current landscape of anti-spam tools since I
> haven't set up a new system in a while, and one place I'm wondering
> what people are using is milters for spamassassin/spamc.
>
> It seems like spamass-milter is the default go-to for most people, but
> I'd really like one that can listen on an INET socket (and
> spamass-milter doesn't as far as I can tell, but please correct me if
> I'm wrong). Milter-spamc from SnertSoft looks promising, but it's not
> free, and a bit more complicated. smtp-vilter also looks interesting,
> but it does more than just SpamAssassin stuff, so might be overkill.
>
> And I suspect there are a bunch more out there (though a lot of these
> projects seem to have stalled or died over time).
>
> What are your favorite (not spamass-milter) options for plugging
> spamassassin into a milter?
MIMEDefang. Chosen many years ago, never had an adequate reason to
switch. Its primary strengths:
1. It is a hub for all content filtering, not just SA, so you get
deterministic but flexible filter ordering.
2. It is primarily configured by a set of Perl subroutine
implementations. If you can write the Perl for a particular filtering
trick, you can implement it in MD.
3. It is designed to work with messages as possibly complex MIME
objects, providing the framework for sophisticated safe manipulation of
messages and their parts.
4. It is mature open source software that is actively supported.
5. It does not use a running spamd, but rather uses its own herd of
filtering slaves that load the SA modules.
Re: Which milter do you prefer?
Posted by Reindl Harald <h....@thelounge.net>.
Am 14.03.2015 um 14:08 schrieb shanew@shanew.net:
> On Fri, 13 Mar 2015, David B Funk wrote:
>
>> Looking at the source for spamass-milter it looks like they're taking
>> the "-p socket" argument and passing it directly to smfi_setconn so
>> you should be able to give an INET socket address if you use the
>> correct syntax (see docs for smfi_setconn).
>
> The spamass-milter mailing list says you can't do this (and I don't
> think the post about it was _that_ old), but I should probably give it
> a try anyway. Worst thing that happens is that it doesn't work
normally spamass-milter runs on the MTA and the params after "--" are
for spamc, so you have spamd running on whatever host and instruct all
milters on MTA's to use these host / hosts over TCP
/usr/sbin/spamass-milter -p /run/spamass-milter/spamass-milter.sock -g
sa-milt -r 8.0 -- -s 5242880 --port=10028
Usage: spamass-milter -p socket [-b|-B bucket] [-d xx[,yy...]] [-D host]
[-e defaultdomain] [-f] [-i networks] [-I] [-m] [-M]
[-P pidfile] [-r nn] [-u defaultuser] [-x] [-a]
[-C rejectcode] [-R rejectmsg] [-g group]
[-- spamc args ]
-p socket: path to create socket
-b bucket: redirect spam to this mail address. The orignal
recipient(s) will not receive anything.
-B bucket: add this mail address as a BCC recipient of spam.
-C RejectCode: using this Reject Code.
-d xx[,yy ...]: set debug flags. Logs to syslog
-D host: connect to spamd at remote host (deprecated)
-e defaultdomain: pass full email address to spamc instead of just
username. Uses 'defaultdomain' if there was none
-f: fork into background
-g group: socket group (perms to 660 as well)
-i: skip (ignore) checks from these IPs or netblocks
example: -i 192.168.12.5,10.0.0.0/8,172.16.0.0/255.255.0.0
-I: skip (ignore) checks if sender is authenticated
-m: don't modify body, Content-type: or Subject:
-M: don't modify the message at all
-P pidfile: Put processid in pidfile
-r nn: reject messages with a score >= nn with an SMTP error.
use -1 to reject any messages tagged by SA.
-R RejectText: using this Reject Text.
-u defaultuser: pass the recipient's username to spamc.
Uses 'defaultuser' if there are multiple recipients.
-x: pass email address through alias and virtusertable expansion.
-a: don't scan messages over an authenticated connection.
-- spamc args: pass the remaining flags to spamc
Re: Which milter do you prefer?
Posted by sh...@shanew.net.
On Fri, 13 Mar 2015, David B Funk wrote:
> Looking at the source for spamass-milter it looks like they're taking
> the "-p socket" argument and passing it directly to smfi_setconn so
> you should be able to give an INET socket address if you use the
> correct syntax (see docs for smfi_setconn).
The spamass-milter mailing list says you can't do this (and I don't
think the post about it was _that_ old), but I should probably give it
a try anyway. Worst thing that happens is that it doesn't work.
--
Public key #7BBC68D9 at | Shane Williams
http://pgp.mit.edu/ | System Admin - UT CompSci
=----------------------------------+-------------------------------
All syllogisms contain three lines | shanew@shanew.net
Therefore this is not a syllogism | www.ischool.utexas.edu/~shanew
Re: Which milter do you prefer?
Posted by sh...@shanew.net.
I just wanted to report that, despite what the spamass-milter mailing
list has to say, you can in fact hand spamass-milter an inet socket in
the config and it will happily listen on the network. That'll teach
me to not just try stuff.
Also, thanks to everyone who had suggestions on specific milters as
well as "glue" for multiple filters. I knew about many, but not all
of them, so it's given me lots to investigate (and in some cases
rediscover).
On Fri, 13 Mar 2015, David B Funk wrote:
> On Fri, 13 Mar 2015, Shane Williams wrote:
>
>> I've been reviewing the current landscape of anti-spam tools since I
>> haven't set up a new system in a while, and one place I'm wondering
>> what people are using is milters for spamassassin/spamc.
>>
>> It seems like spamass-milter is the default go-to for most people, but
>> I'd really like one that can listen on an INET socket (and
>> spamass-milter doesn't as far as I can tell, but please correct me if
>> I'm wrong). Milter-spamc from SnertSoft looks promising, but it's not
>> free, and a bit more complicated. smtp-vilter also looks interesting,
>> but it does more than just SpamAssassin stuff, so might be overkill.
>>
>> And I suspect there are a bunch more out there (though a lot of these
>> projects seem to have stalled or died over time).
>>
>> What are your favorite (not spamass-milter) options for plugging
>> spamassassin into a milter?
>
> Looking at the source for spamass-milter it looks like they're taking
> the "-p socket" argument and passing it directly to smfi_setconn so
> you should be able to give an INET socket address if you use the
> correct syntax (see docs for smfi_setconn).
>
> 13 years ago I was doing a hunt similar to yours and came across
> "miltrassassin" from digitalanswers.org. It was not quite what I
> was looking for but closer than any of the others I found, so I took
> it and started developing.
>
>
>
>
>
--
Public key #7BBC68D9 at | Shane Williams
http://pgp.mit.edu/ | System Admin - UT CompSci
=----------------------------------+-------------------------------
All syllogisms contain three lines | shanew@shanew.net
Therefore this is not a syllogism | www.ischool.utexas.edu/~shanew
Re: Which milter do you prefer?
Posted by David B Funk <db...@engineering.uiowa.edu>.
On Fri, 13 Mar 2015, Shane Williams wrote:
> I've been reviewing the current landscape of anti-spam tools since I
> haven't set up a new system in a while, and one place I'm wondering
> what people are using is milters for spamassassin/spamc.
>
> It seems like spamass-milter is the default go-to for most people, but
> I'd really like one that can listen on an INET socket (and
> spamass-milter doesn't as far as I can tell, but please correct me if
> I'm wrong). Milter-spamc from SnertSoft looks promising, but it's not
> free, and a bit more complicated. smtp-vilter also looks interesting,
> but it does more than just SpamAssassin stuff, so might be overkill.
>
> And I suspect there are a bunch more out there (though a lot of these
> projects seem to have stalled or died over time).
>
> What are your favorite (not spamass-milter) options for plugging
> spamassassin into a milter?
Looking at the source for spamass-milter it looks like they're taking
the "-p socket" argument and passing it directly to smfi_setconn so
you should be able to give an INET socket address if you use the
correct syntax (see docs for smfi_setconn).
13 years ago I was doing a hunt similar to yours and came across
"miltrassassin" from digitalanswers.org. It was not quite what I
was looking for but closer than any of the others I found, so I took
it and started developing.
--
Dave Funk University of Iowa
<dbfunk (at) engineering.uiowa.edu> College of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center
Sys_admin/Postmaster/cell_admin Iowa City, IA 52242-1527
#include <std_disclaimer.h>
Better is not better, 'standard' is better. B{
Re: Which milter do you prefer?
Posted by Ted Mittelstaedt <te...@ipinc.net>.
spamass-milter
I don't have enough hours in the day to troubleshoot some effing stupid
incompatibility between the latest version of SA and the latest version
of BrandX milter that crops up when SA is updated, nor to listen to
the complaining while the milter is offline while I'm fixing it. At
least this way I can pretend to myself that someone actually did some
modicum of testing the two pieces of software together before release ;-)
I can tell you, though, that 90% of the "which way did he go which way
did he go"* Linux admins out there just go with whatever the Linux
distro maintainers say to use in their HowTows and that seems currently
to be amavisd+postfix, no milter involved.
Ted
*You won't understand the reference unless you have been raised on Bugs
Bunny cartoons. ;-)
On 3/13/2015 2:41 PM, Shane Williams wrote:
> I've been reviewing the current landscape of anti-spam tools since I
> haven't set up a new system in a while, and one place I'm wondering
> what people are using is milters for spamassassin/spamc.
>
> It seems like spamass-milter is the default go-to for most people, but
> I'd really like one that can listen on an INET socket (and
> spamass-milter doesn't as far as I can tell, but please correct me if
> I'm wrong). Milter-spamc from SnertSoft looks promising, but it's not
> free, and a bit more complicated. smtp-vilter also looks interesting,
> but it does more than just SpamAssassin stuff, so might be overkill.
>
> And I suspect there are a bunch more out there (though a lot of these
> projects seem to have stalled or died over time).
>
> What are your favorite (not spamass-milter) options for plugging
> spamassassin into a milter?
>
Re: Which milter do you prefer?
Posted by Benny Pedersen <me...@junc.eu>.
Ted Mittelstaedt skrev den 2015-03-13 23:33:
> Must be something in the water! Or maybe it's just Friday...
and 13
Re: Which milter do you prefer?
Posted by Ted Mittelstaedt <te...@ipinc.net>.
> want to avoid the usual distro based dependency parties
Yeah, right!
Now your the one looking to start a holy-war...
Must be something in the water! Or maybe it's just Friday...
Ted
On 3/13/2015 3:19 PM, Axb wrote:
> On 03/13/2015 10:41 PM, Shane Williams wrote:
>> I've been reviewing the current landscape of anti-spam tools since I
>> haven't set up a new system in a while, and one place I'm wondering
>> what people are using is milters for spamassassin/spamc.
>>
>> It seems like spamass-milter is the default go-to for most people, but
>> I'd really like one that can listen on an INET socket (and
>> spamass-milter doesn't as far as I can tell, but please correct me if
>> I'm wrong). Milter-spamc from SnertSoft looks promising, but it's not
>> free, and a bit more complicated. smtp-vilter also looks interesting,
>> but it does more than just SpamAssassin stuff, so might be overkill.
>>
>> And I suspect there are a bunch more out there (though a lot of these
>> projects seem to have stalled or died over time).
>>
>> What are your favorite (not spamass-milter) options for plugging
>> spamassassin into a milter?
>>
>
> If you need to handle lots of traffic FAST and want to avoid the usual
> distro based dependency parties, yet not compromise on flexibility,
> etc., Haraka is you friend.
>
> https://haraka.github.io/
>
>
Re: Which milter do you prefer?
Posted by Axb <ax...@gmail.com>.
On 03/13/2015 10:41 PM, Shane Williams wrote:
> I've been reviewing the current landscape of anti-spam tools since I
> haven't set up a new system in a while, and one place I'm wondering
> what people are using is milters for spamassassin/spamc.
>
> It seems like spamass-milter is the default go-to for most people, but
> I'd really like one that can listen on an INET socket (and
> spamass-milter doesn't as far as I can tell, but please correct me if
> I'm wrong). Milter-spamc from SnertSoft looks promising, but it's not
> free, and a bit more complicated. smtp-vilter also looks interesting,
> but it does more than just SpamAssassin stuff, so might be overkill.
>
> And I suspect there are a bunch more out there (though a lot of these
> projects seem to have stalled or died over time).
>
> What are your favorite (not spamass-milter) options for plugging
> spamassassin into a milter?
>
If you need to handle lots of traffic FAST and want to avoid the usual
distro based dependency parties, yet not compromise on flexibility,
etc., Haraka is you friend.
https://haraka.github.io/
Re: Which milter do you prefer?
Posted by Noel Butler <no...@ausics.net>.
Doesn't always mean nobody's home, I have great hesitation in using
something that releases often, its an indication the developer(s) are
hopeless, especially if its constant bug fixes - you only need to look
at phpmy.... as an example, it used to be good, but in recent years,
dev_#1 brought on more people, since then, frankly its gone to shit and
there are updates weekly, sometimes twice a week, its well beyond a
joke.
Yes compilers change, but good coders anticipate this, for example dnews
hasn't been updated since 2008 which was only a minor change for those
feeding off giganews at the time (they sent an unusual AUTH response, so
only a line of code extra IIRC), its base code however is circa _2004_
yet runs fine on modern 32 bit systems - thats a sign of clever devs,
its does the job fine, better than anything else around even today
(barring 64bit ability and its lack of IPv6 which is easy enough to work
around anyway), so there is the proof just because somethings not
updated in many years it isnt always a bad thing.
On 15/03/2015 11:27, Greg Troxel wrote:
> An update every 18-24 months would have been fine, even if there were
> only minor bug fixes. I was pointing out that the interval between
> releases was 8 years. That's enough time for compilers to change and
> generate new warnings, and various other things, so not having a release
> in 8 years is a clue that on one is home upsteram. In the case of
Re: Which milter do you prefer?
Posted by Greg Troxel <gd...@ir.bbn.com>.
"@lbutlr" <kr...@kreme.com> writes:
> On 13 Mar 2015, at 17:54 , Greg Troxel <gd...@ir.bbn.com> wrote:
>> Currently I'm using spamass-milter, which seems to have been teetering
>> on the edge of unmaintained, although the 0.4.0 release on 2014-09-11
>> staved that off for a while. Note that the previous release was
>> 2006-04-05
>
> I’m not sure how important it is that it seem frequent updates. It’s
> really just a conduit between spamassassin and sendmail. I wouldn’t
> think it would need much in the way of development, the work is all on
> the other ends.
An update every 18-24 months would have been fine, even if there were
only minor bug fixes. I was pointing out that the interval between
releases was 8 years. That's enough time for compilers to change and
generate new warnings, and various other things, so not having a release
in 8 years is a clue that on one is home upsteram. In the case of
spamass-milter, there were various patches accumulating in pkgsrc, and
it seemed no one was home upstream, until someone stepped up to apply
patches and make a new release.
Re: Which milter do you prefer?
Posted by "Kevin A. McGrail" <KM...@PCCC.com>.
On 3/14/2015 1:31 PM, Reindl Harald wrote:
>
> hm - that's all additional layers leading to more complexity
>
> couldn't SA at the end internally cut the message after configuration
> value XX size for scanning while add the headers to the unaltered
> version?
Sure but I have lots of feature requests and not so many coders. Plus I
have a solution that works for me and lots of other stuff that takes my
priority. Perhaps someone will be inspired by the idea to bang out a
patch because it does work well for us in real-world testing.
Regards,
KAM
Re: Which milter do you prefer?
Posted by Reindl Harald <h....@thelounge.net>.
Am 14.03.2015 um 18:27 schrieb Kevin A. McGrail:
> On 3/14/2015 12:08 PM, Reindl Harald wrote:
>> how do you truncate messages for the scan?
> I use MD and pass the load average for the box to the milter. From
> there, depending on the load average, I chop large messages to be
> smaller and send them to SA for classification. We then use the score
> and required threshhold to handle the email as Spam or not.
>
> David added some more of his tricks and tips with MIME::Tools and MD.
>
> Anyway, happy to discuss in detail on the MD list the recipes, etc.
> though I've posted there about them before.
hm - that's all additional layers leading to more complexity
couldn't SA at the end internally cut the message after configuration
value XX size for scanning while add the headers to the unaltered version?
Re: Which milter do you prefer?
Posted by "Kevin A. McGrail" <KM...@PCCC.com>.
On 3/14/2015 12:08 PM, Reindl Harald wrote:
> how do you truncate messages for the scan?
I use MD and pass the load average for the box to the milter. From
there, depending on the load average, I chop large messages to be
smaller and send them to SA for classification. We then use the score
and required threshhold to handle the email as Spam or not.
David added some more of his tricks and tips with MIME::Tools and MD.
Anyway, happy to discuss in detail on the MD list the recipes, etc.
though I've posted there about them before.
regards,
KAM
Re: Handling very large messages (was Re: Which milter do you
prefer?)
Posted by "David F. Skoll" <df...@roaringpenguin.com>.
On Mon, 16 Mar 2015 10:51:59 -0400
"Bill Cole" <sa...@billmail.scconsult.com> wrote:
> Is the code for doing this shared anywhere or is it sharable? Please?
It's part of our commercial CanIt software. But I can post a
chunk of Perl that's roughly what we do.
We parse the message into a MIME::Entity. Then if we need to truncate
it, we call a function similar to the code shown below. It generates a
version of the message with all non-text parts emptied out. It's a really
evil hack.
Code is for your education. Most likely needs considerable tweaking
for production; our real production code obviously is much more
sophisticated.
Regards,
David.
# Pass the function below a MIME entity. It returns a file handle
# opened for reading on a truncated message body.
sub open_truncated_body
{
my($mime_entity) = @_;
# We are truncating non-text parts. So
# we override print_body... ugh.
no warnings 'redefine'; ## no critic (NoWarnings)
my $original_print_bodyhandle = *MIME::Entity::print_bodyhandle{'CODE'};
local *MIME::Entity::print_bodyhandle = sub {
my($self, $out) = @_;
$out ||= select;
if ($self->head->mime_type =~ m|^text/|) {
# Evil...
# TODO FIXME: per ticket 15530, need to cap
# the size of text/* attachments.
# Unfortunately, the only way to do this may
# require even more evil.
return &$original_print_bodyhandle($self, $out);
}
# Leave empty!!!
return 1;
};
my $fh = IO::File->new('TRUNCATED-MSG', O_WRONLY|O_CREAT);
if ($fh && $fh->opened) {
$mime_entity->print($fh);
$fh->close();
} else {
return undef;
}
return IO::File->new('TRUNCATED-MSG', O_RDONLY);
}
Re: Handling very large messages (was Re: Which milter do you
prefer?)
Posted by Bill Cole <sa...@billmail.scconsult.com>.
On 14 Mar 2015, at 12:55, David F. Skoll wrote:
[...]
> I can't answer for Kevin, but what we do is this: For oversize
> messages, we remove non text/* attachments. If they're still
> oversize, we truncate the text/plain parts. If they're still
> oversize, we truncate the text/html parts. We do this very carefully
> with MIME::tools to ensure that SpamAssassin always sees a valid MIME
> message and not (for example) one with a missing boundary.
>
> We use MIMEDefang for SpamAssassin integration, so we can play
> whatever
> tricks we like with the data that gets passed to SpamAssassin without
> actually messing with the original message.
Is the code for doing this shared anywhere or is it sharable? Please?
(1. I'm lazy 2. I'm not egotistical enough to think my own MD code
wouldn't be objective worse than yours)
Re: Handling very large messages (was Re: Which milter do you prefer?)
Posted by Robert Schetterer <rs...@sys4.de>.
Am 16.03.2015 um 19:30 schrieb Reindl Harald:
>
>
> Am 16.03.2015 um 19:24 schrieb Robert Schetterer:
>> Am 16.03.2015 um 18:33 schrieb Reindl Harald:
>>> Am 16.03.2015 um 18:19 schrieb Matus UHLAR - fantomas:
>>>> On 16.03.15 00:59, Jude DaShiell wrote:
>>>>> I have been getting large spam messages for several years on one of my
>>>>> accounts. Since spamassassin cannot handle them, my only recourse are
>>>>> procmail recipes.
>>>>
>>>> spamassassin CAN handle them. I have ocnfigued spamass-milter to
>>>> process
>>>> all
>>>> mail (by setting size to the same as maximum alllowed mail size) and it
>>>> does...
>>>>
>>>> it't just the spamc default that is 512K. spamd maximum is 512M
>>>> afaik, I
>>>> don't think you receive such big mail...
>>>
>>> depends on the amount and content of mails since it skips binary
>>> attachment contents
>>>
>>> try really large plaintext content and it takes more than 10 seconds per
>>> message with 100% CPU load - you will notice that quickly ba attach a
>>> large plaintext logfile in case of spamass-milter on a submission server
>>> because it ends in a client timeout
>>>
>>
>> dont use spamass-milter with submission, its to slow
>
> only for large plaintext content which is the topic of that thread
as i tested it, and judged it unacceptable slow in real world setups
but this maybe different elsewhere
>
>> clamav-milter with sanesecurity fits better ( faster )
>
> but it don't find anything countable
>
> here are a lot of sanesecurity signatures active (inbound MX) and
> because the low hit-rate i ordered it finally after SA which catchs much
> more and so one content-scanner can be skipped in many cases
>
>> after all outbound spam scanning is difficult ever
>
> but sadly needed in case of hacked accounts, in the past more than once
> even masked a successful dictionary attack because the bot did not
> realize the successful SASL login and continued try other passwords
> after the milter-reject
>
mailadmins are not promised to have an easy life *g
a better use would be some "abnormality" detection system for catching
hacked accounts, i.e with profiling normal user behave and compare..
Some simple reject match i.e might be many logins from wide different
geo ip locations in short time periods etc
this might help too in some setups
https://www.roessner-network-solutions.com/postfix-milter-vrfydmn/
https://github.com/croessner/vrfydmn
...
2nd scenarion
You provde mail services for customers that deliver their mail over
submission. If you have infected PCs where bots are going to send mails
over users account, they can fake the sender addresses.
...
Best Regards
MfG Robert Schetterer
--
[*] sys4 AG
http://sys4.de, +49 (89) 30 90 46 64
Franziskanerstraße 15, 81669 München
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein
Re: Handling very large messages (was Re: Which milter do you prefer?)
Posted by Reindl Harald <h....@thelounge.net>.
Am 16.03.2015 um 19:24 schrieb Robert Schetterer:
> Am 16.03.2015 um 18:33 schrieb Reindl Harald:
>> Am 16.03.2015 um 18:19 schrieb Matus UHLAR - fantomas:
>>> On 16.03.15 00:59, Jude DaShiell wrote:
>>>> I have been getting large spam messages for several years on one of my
>>>> accounts. Since spamassassin cannot handle them, my only recourse are
>>>> procmail recipes.
>>>
>>> spamassassin CAN handle them. I have ocnfigued spamass-milter to process
>>> all
>>> mail (by setting size to the same as maximum alllowed mail size) and it
>>> does...
>>>
>>> it't just the spamc default that is 512K. spamd maximum is 512M afaik, I
>>> don't think you receive such big mail...
>>
>> depends on the amount and content of mails since it skips binary
>> attachment contents
>>
>> try really large plaintext content and it takes more than 10 seconds per
>> message with 100% CPU load - you will notice that quickly ba attach a
>> large plaintext logfile in case of spamass-milter on a submission server
>> because it ends in a client timeout
>>
>
> dont use spamass-milter with submission, its to slow
only for large plaintext content which is the topic of that thread
> clamav-milter with sanesecurity fits better ( faster )
but it don't find anything countable
here are a lot of sanesecurity signatures active (inbound MX) and
because the low hit-rate i ordered it finally after SA which catchs much
more and so one content-scanner can be skipped in many cases
> after all outbound spam scanning is difficult ever
but sadly needed in case of hacked accounts, in the past more than once
even masked a successful dictionary attack because the bot did not
realize the successful SASL login and continued try other passwords
after the milter-reject
Re: Handling very large messages (was Re: Which milter do you prefer?)
Posted by Robert Schetterer <rs...@sys4.de>.
Am 16.03.2015 um 18:33 schrieb Reindl Harald:
>
>
> Am 16.03.2015 um 18:19 schrieb Matus UHLAR - fantomas:
>> On 16.03.15 00:59, Jude DaShiell wrote:
>>> I have been getting large spam messages for several years on one of my
>>> accounts. Since spamassassin cannot handle them, my only recourse are
>>> procmail recipes.
>>
>> spamassassin CAN handle them. I have ocnfigued spamass-milter to process
>> all
>> mail (by setting size to the same as maximum alllowed mail size) and it
>> does...
>>
>> it't just the spamc default that is 512K. spamd maximum is 512M afaik, I
>> don't think you receive such big mail...
>
> depends on the amount and content of mails since it skips binary
> attachment contents
>
> try really large plaintext content and it takes more than 10 seconds per
> message with 100% CPU load - you will notice that quickly ba attach a
> large plaintext logfile in case of spamass-milter on a submission server
> because it ends in a client timeout
>
dont use spamass-milter with submission, its to slow, clamav-milter with
sanesecurity fits better ( faster ), after all outbound spam scanning is
difficult ever
Best Regards
MfG Robert Schetterer
--
[*] sys4 AG
http://sys4.de, +49 (89) 30 90 46 64
Franziskanerstraße 15, 81669 München
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein
Re: Handling very large messages (was Re: Which milter do you prefer?)
Posted by Reindl Harald <h....@thelounge.net>.
Am 16.03.2015 um 18:19 schrieb Matus UHLAR - fantomas:
> On 16.03.15 00:59, Jude DaShiell wrote:
>> I have been getting large spam messages for several years on one of my
>> accounts. Since spamassassin cannot handle them, my only recourse are
>> procmail recipes.
>
> spamassassin CAN handle them. I have ocnfigued spamass-milter to process
> all
> mail (by setting size to the same as maximum alllowed mail size) and it
> does...
>
> it't just the spamc default that is 512K. spamd maximum is 512M afaik, I
> don't think you receive such big mail...
depends on the amount and content of mails since it skips binary
attachment contents
try really large plaintext content and it takes more than 10 seconds per
message with 100% CPU load - you will notice that quickly ba attach a
large plaintext logfile in case of spamass-milter on a submission server
because it ends in a client timeout
Re: Handling very large messages (was Re: Which milter do you
prefer?)
Posted by Matus UHLAR - fantomas <uh...@fantomas.sk>.
On 16.03.15 00:59, Jude DaShiell wrote:
>I have been getting large spam messages for several years on one of
>my accounts. Since spamassassin cannot handle them, my only recourse
>are procmail recipes.
spamassassin CAN handle them. I have ocnfigued spamass-milter to process all
mail (by setting size to the same as maximum alllowed mail size) and it
does...
it't just the spamc default that is 512K. spamd maximum is 512M afaik, I
don't think you receive such big mail...
--
Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Your mouse has moved. Windows NT will now restart for changes to take
to take effect. [OK]
Re: Handling very large messages (was Re: Which milter do you
prefer?)
Posted by Matus UHLAR - fantomas <uh...@fantomas.sk>.
>Am 15.03.2015 um 19:03 schrieb Axb:
>>IMO, deciding what chunk of a msg should be scanned should be managed by
>>the glue and not by SA.
On 15.03.15 19:09, Reindl Harald wrote:
>true but if the glue (spamass-milter) would truncate the message it
>passes to spamc it would get back that truncated message with the
>added headers (which are used to decide reject or pass) and so
>finally *deliver* the truncated version
You can turn this off with option "-m" for spamass-milter, so only
"X-Spam-*" headers will be added.
With this you can pass option "--headers" to spamc, which only returns
modified headers by spamd.
--
Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Due to unexpected conditions Windows 2000 will be released
in first quarter of year 1901
Re: Handling very large messages (was Re: Which milter do you
prefer?)
Posted by Jude DaShiell <jd...@panix.com>.
I have been getting large spam messages for several years on one of my
accounts. Since spamassassin cannot handle them, my only recourse are
procmail recipes.
-- Twitter: JudeDaShiell
On Sun, 15 Mar 2015, Robert Schetterer wrote:
> Am 15.03.2015 um 12:05 schrieb Reindl Harald:
>>
>> Am 14.03.2015 um 20:17 schrieb Robert Schetterer:
>>> Am 14.03.2015 um 18:11 schrieb Reindl Harald:
>>>> nobody but talks about cut content
>>>>
>>>> we talk about how to pass only a part to spamassassin instead skip large
>>>> messages entirely which in many case would be enough to detect a message
>>>> as spam because the "oversize" are just binary parts
>>>
>>> Ok, but big spam mails are extrem rare, i wouldnt invest time in that
>>
>> you are so terrible wrong
>
> my intention was never to agree with you
>
>>
>> more and more spam messages are coming with a very large image because
>> spammers know the default 256 KB limit which also affects commercial
>> products like from Barracuda Networks, that is not a new trend
>>
>> there is a reason for "-s 5242880" in our setup while i started with "-s
>> 786432" a few months ago
>>
>
> as i wrote this may happen at your site, you should not set your
> experience as ultimate
> everyone has his/its own spam, i dont see any rise in large mail spam here
>
> back to topic i would recommend a two stage spam filtering, if you got
> in trouble with "big spam mail", i.e spamass-milter in front line, then
> "perhaps" combine sieve filters with size/spam matches etc
>
> Best Regards
> MfG Robert Schetterer
>
>
Re: Handling very large messages (was Re: Which milter do you
prefer?)
Posted by "David F. Skoll" <df...@roaringpenguin.com>.
On Sun, 15 Mar 2015 14:19:17 -0500 (CDT)
Dave Funk <db...@engineering.uiowa.edu> wrote:
> However that glue can be intelligent and contain business logic.
And getting back to the original topic... that is why my favorite
milter is MIMEDefang. :)
It does integrate with SpamAssassin, but it also lets you write your own
business logic in Perl which can make for a very powerful combination.
Regards,
David.
Re: Handling very large messages (was Re: Which milter do you
prefer?)
Posted by Dave Funk <db...@engineering.uiowa.edu>.
On Sun, 15 Mar 2015, Reindl Harald wrote:
>
>
> Am 15.03.2015 um 19:15 schrieb Axb:
>> On 03/15/2015 07:09 PM, Reindl Harald wrote:
>>>
[snip..]
>>>> IMO, deciding what chunk of a msg should be scanned should be managed by
>>>> the glue and not by SA.
>>>
>>> true but if the glue (spamass-milter) would truncate the message it
>>> passes to spamc it would get back that truncated message with the added
>>> headers (which are used to decide reject or pass) and so finally
>>> *deliver* the truncated version
>>
>> then spamass-milter is the wrong choice
>
> how else should it work?
>
> it hardly can invent the report-headers SA adds by itself which needs to land
> in the final message, spamc/spamd are doing the message work and the milter
> is just the glue to bring the MTA and SA together
However that glue can be intelligent and contain business logic.
If the author of the milter knows what they are doing (and cares) this is
very straightforward thing to do (I know because I did it with
milterassassin).
In the milter you must take an explicit extra step if you want to mess
with the body of the message (smfi_replacebody). It's actually easier to
just add/replace headers (smfi_addheader/smfi_chgheader) then it is
to mess with the body. (not to mention faster & more efficient).
So logic is; milter receives -copy- of message from sendmail, milter
passes 'REPORT' command & (optionally truncated) message to spamd, gets
back a headers-only report. milter then tells sendmail to add the
new/modified headers and doesn't mess with the body.
--
Dave Funk University of Iowa
<dbfunk (at) engineering.uiowa.edu> College of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center
Sys_admin/Postmaster/cell_admin Iowa City, IA 52242-1527
#include <std_disclaimer.h>
Better is not better, 'standard' is better. B{
Re: Handling very large messages (was Re: Which milter do you prefer?)
Posted by Axb <ax...@gmail.com>.
On 03/15/2015 09:27 PM, Reindl Harald wrote:
>
> Am 15.03.2015 um 21:12 schrieb Axb:
>> On 03/15/2015 09:00 PM, Reindl Harald wrote:
>>>>> that could be even a sloppy implementation just truncate after XX
>>>>> bytes
>>>>> and analyze the remaining piece to keep that part simple and fast - at
>>>>> the end it would improve the result with as less as possible overhead
>>>>> and code compared to skip a message
>>>>
>>>> that wheel has been invented... and quite a few do it right. Your
>>>> choice
>>>> of glue is not one of them. And SA shouldn't follow the bad examples
>>>
>>> no - problems in general should be solved at the root cause
>>>
>>> the root cause is that SA is overwhelmed with large mails and so instead
>>> work around that problem in every glue on that planet it just should
>>> only scan the amount of a message it can handle
>>>
>>> you may disagree because bounce that burden to the glue needs no effort
>>> on your side, but that don't make it right
>>
>> if you think SA is "overwhelmed" then it's definitely the wrong tool for
>> you.
>>
>> maybe you should try rspamd (https://rspamd.com/)
>
> come on, stop that attitude
> what is the reason that you feel always attacked and suggest people
> should creep away instead see constructive criticism as positive and
> helpful over the long?
I'm trying to suggest options which may help you instead of expecting SA
to bend backwards just coz you think it should.
SA is the most inneficient link in the chain, so it wouldn't be very
smart to do what you suggest when it should be tackled before SA sees
any content.
> otherwise the default for spamc of 500k and sa-learn of 256k won't exist
> which are both raised here to much larger values after find out the
> amount of skipped messages for scanning and ignored messages for training
SA is a framework - per default, with conservative settings, it works
very well for most ppl, those who prefer other values can and will
change them.
Many ppl even fork it and bend it to fit their needs.
RIP horse.. I'm outta here
Re: Handling very large messages (was Re: Which milter do you prefer?)
Posted by Reindl Harald <h....@thelounge.net>.
Am 15.03.2015 um 21:12 schrieb Axb:
> On 03/15/2015 09:00 PM, Reindl Harald wrote:
>>>> that could be even a sloppy implementation just truncate after XX bytes
>>>> and analyze the remaining piece to keep that part simple and fast - at
>>>> the end it would improve the result with as less as possible overhead
>>>> and code compared to skip a message
>>>
>>> that wheel has been invented... and quite a few do it right. Your choice
>>> of glue is not one of them. And SA shouldn't follow the bad examples
>>
>> no - problems in general should be solved at the root cause
>>
>> the root cause is that SA is overwhelmed with large mails and so instead
>> work around that problem in every glue on that planet it just should
>> only scan the amount of a message it can handle
>>
>> you may disagree because bounce that burden to the glue needs no effort
>> on your side, but that don't make it right
>
> if you think SA is "overwhelmed" then it's definitely the wrong tool for
> you.
>
> maybe you should try rspamd (https://rspamd.com/)
come on, stop that attitude
what is the reason that you feel always attacked and suggest people
should creep away instead see constructive criticism as positive and
helpful over the long?
not i think it is overwhelmed, the SA developers do
otherwise the default for spamc of 500k and sa-learn of 256k won't exist
which are both raised here to much larger values after find out the
amount of skipped messages for scanning and ignored messages for training
-s, --max-size size Specify maximum message size, in bytes.
[default: 500k]
--max-size <b> Skip messages larger than b bytes;
defaults to 256 KiB, 0 implies no limit
Re: Handling very large messages (was Re: Which milter do you prefer?)
Posted by Axb <ax...@gmail.com>.
On 03/15/2015 09:00 PM, Reindl Harald wrote:
>
>
> Am 15.03.2015 um 20:35 schrieb Axb:
>> On 03/15/2015 08:22 PM, Reindl Harald wrote:
>>>
>>> Am 15.03.2015 um 19:50 schrieb Martin Gregorie:
>>>> On Sun, 2015-03-15 at 19:23 +0100, Reindl Harald wrote:
>>>>>
>>>>> Am 15.03.2015 um 19:15 schrieb Axb:
>>>>>>> true but if the glue (spamass-milter) would truncate the message it
>>>>>>> passes to spamc it would get back that truncated message with the
>>>>>>> added
>>>>>>> headers (which are used to decide reject or pass) and so finally
>>>>>>> *deliver* the truncated version
>>>>>>
>>>>>> then spamass-milter is the wrong choice
>>>>>
>>>>> how else should it work?
>>>>>
>>>>> it hardly can invent the report-headers SA adds by itself which
>>>>> needs to
>>>>> land in the final message, spamc/spamd are doing the message work and
>>>>> the milter is just the glue to bring the MTA and SA together
>>>>>
>>>> No but, as others have suggested, if the glue shortens the message by
>>>> using MIME-aware code to remove binary attachments, it should be
>>>> easy to
>>>> keep them while spamd scans the shortened message and then put them
>>>> back
>>>> before the message is sent on downstream
>>>
>>> that's error prone and assumes that all mails are 100% valid
>>>
>>> adding headers is a dead safe process
>>> mangle other parts of a mail is not
>>>
>>> hence the only safe and right thing to do is have SA internally work
>>> with a truncated version for analyze transparent to the glue and other
>>> components or just continue with skip messages above a defined size from
>>> scanning at all
>>>
>>> that could be even a sloppy implementation just truncate after XX bytes
>>> and analyze the remaining piece to keep that part simple and fast - at
>>> the end it would improve the result with as less as possible overhead
>>> and code compared to skip a message
>>
>> that wheel has been invented... and quite a few do it right. Your choice
>> of glue is not one of them. And SA shouldn't follow the bad examples
>
> no - problems in general should be solved at the root cause
>
> the root cause is that SA is overwhelmed with large mails and so instead
> work around that problem in every glue on that planet it just should
> only scan the amount of a message it can handle
>
> you may disagree because bounce that burden to the glue needs no effort
> on your side, but that don't make it right
if you think SA is "overwhelmed" then it's definitely the wrong tool for
you.
maybe you should try rspamd (https://rspamd.com/)
Re: Handling very large messages (was Re: Which milter do you prefer?)
Posted by Reindl Harald <h....@thelounge.net>.
Am 15.03.2015 um 20:35 schrieb Axb:
> On 03/15/2015 08:22 PM, Reindl Harald wrote:
>>
>> Am 15.03.2015 um 19:50 schrieb Martin Gregorie:
>>> On Sun, 2015-03-15 at 19:23 +0100, Reindl Harald wrote:
>>>>
>>>> Am 15.03.2015 um 19:15 schrieb Axb:
>>>>>> true but if the glue (spamass-milter) would truncate the message it
>>>>>> passes to spamc it would get back that truncated message with the
>>>>>> added
>>>>>> headers (which are used to decide reject or pass) and so finally
>>>>>> *deliver* the truncated version
>>>>>
>>>>> then spamass-milter is the wrong choice
>>>>
>>>> how else should it work?
>>>>
>>>> it hardly can invent the report-headers SA adds by itself which
>>>> needs to
>>>> land in the final message, spamc/spamd are doing the message work and
>>>> the milter is just the glue to bring the MTA and SA together
>>>>
>>> No but, as others have suggested, if the glue shortens the message by
>>> using MIME-aware code to remove binary attachments, it should be easy to
>>> keep them while spamd scans the shortened message and then put them back
>>> before the message is sent on downstream
>>
>> that's error prone and assumes that all mails are 100% valid
>>
>> adding headers is a dead safe process
>> mangle other parts of a mail is not
>>
>> hence the only safe and right thing to do is have SA internally work
>> with a truncated version for analyze transparent to the glue and other
>> components or just continue with skip messages above a defined size from
>> scanning at all
>>
>> that could be even a sloppy implementation just truncate after XX bytes
>> and analyze the remaining piece to keep that part simple and fast - at
>> the end it would improve the result with as less as possible overhead
>> and code compared to skip a message
>
> that wheel has been invented... and quite a few do it right. Your choice
> of glue is not one of them. And SA shouldn't follow the bad examples
no - problems in general should be solved at the root cause
the root cause is that SA is overwhelmed with large mails and so instead
work around that problem in every glue on that planet it just should
only scan the amount of a message it can handle
you may disagree because bounce that burden to the glue needs no effort
on your side, but that don't make it right
Re: Handling very large messages (was Re: Which milter do you prefer?)
Posted by Axb <ax...@gmail.com>.
On 03/15/2015 08:22 PM, Reindl Harald wrote:
>
> Am 15.03.2015 um 19:50 schrieb Martin Gregorie:
>> On Sun, 2015-03-15 at 19:23 +0100, Reindl Harald wrote:
>>>
>>> Am 15.03.2015 um 19:15 schrieb Axb:
>>>>> true but if the glue (spamass-milter) would truncate the message it
>>>>> passes to spamc it would get back that truncated message with the
>>>>> added
>>>>> headers (which are used to decide reject or pass) and so finally
>>>>> *deliver* the truncated version
>>>>
>>>> then spamass-milter is the wrong choice
>>>
>>> how else should it work?
>>>
>>> it hardly can invent the report-headers SA adds by itself which needs to
>>> land in the final message, spamc/spamd are doing the message work and
>>> the milter is just the glue to bring the MTA and SA together
>>>
>> No but, as others have suggested, if the glue shortens the message by
>> using MIME-aware code to remove binary attachments, it should be easy to
>> keep them while spamd scans the shortened message and then put them back
>> before the message is sent on downstream
>
> that's error prone and assumes that all mails are 100% valid
>
> adding headers is a dead safe process
> mangle other parts of a mail is not
>
> hence the only safe and right thing to do is have SA internally work
> with a truncated version for analyze transparent to the glue and other
> components or just continue with skip messages above a defined size from
> scanning at all
>
> that could be even a sloppy implementation just truncate after XX bytes
> and analyze the remaining piece to keep that part simple and fast - at
> the end it would improve the result with as less as possible overhead
> and code compared to skip a message
that wheel has been invented... and quite a few do it right. Your choice
of glue is not one of them. And SA shouldn't follow the bad examples.
Re: Handling very large messages (was Re: Which milter do you prefer?)
Posted by Reindl Harald <h....@thelounge.net>.
Am 15.03.2015 um 19:50 schrieb Martin Gregorie:
> On Sun, 2015-03-15 at 19:23 +0100, Reindl Harald wrote:
>>
>> Am 15.03.2015 um 19:15 schrieb Axb:
>>>> true but if the glue (spamass-milter) would truncate the message it
>>>> passes to spamc it would get back that truncated message with the added
>>>> headers (which are used to decide reject or pass) and so finally
>>>> *deliver* the truncated version
>>>
>>> then spamass-milter is the wrong choice
>>
>> how else should it work?
>>
>> it hardly can invent the report-headers SA adds by itself which needs to
>> land in the final message, spamc/spamd are doing the message work and
>> the milter is just the glue to bring the MTA and SA together
>>
> No but, as others have suggested, if the glue shortens the message by
> using MIME-aware code to remove binary attachments, it should be easy to
> keep them while spamd scans the shortened message and then put them back
> before the message is sent on downstream
that's error prone and assumes that all mails are 100% valid
adding headers is a dead safe process
mangle other parts of a mail is not
hence the only safe and right thing to do is have SA internally work
with a truncated version for analyze transparent to the glue and other
components or just continue with skip messages above a defined size from
scanning at all
that could be even a sloppy implementation just truncate after XX bytes
and analyze the remaining piece to keep that part simple and fast - at
the end it would improve the result with as less as possible overhead
and code compared to skip a message
Re: Handling very large messages (was Re: Which milter do you
prefer?)
Posted by Martin Gregorie <ma...@gregorie.org>.
On Sun, 2015-03-15 at 19:23 +0100, Reindl Harald wrote:
>
> Am 15.03.2015 um 19:15 schrieb Axb:
> > On 03/15/2015 07:09 PM, Reindl Harald wrote:
> >>
> >> Am 15.03.2015 um 19:03 schrieb Axb:
> >>> On 03/15/2015 06:49 PM, Robert Schetterer wrote:
> >>>> Am 15.03.2015 um 18:32 schrieb Robert Schetterer:
> >>>>> tagging is allowed, rejecting is nice but not a must have
> >>>>
> >>>> if you like reject try working in milter chaining with
> >>>> milter-manager http://milter-manager.sourceforge.net/ ( stats
> >>>> included )
> >>>> this gives you option for complex filter scenarios with div milters
> >>>> for size perhaps test combine with milter
> >>>> milter-size
> >>>> http://www.safe-mbox.com/~rgooch/email/index.html
> >>>> and many other milter stuff i.e
> >>>> https://www.milter.org/milter/98
> >>>> MSH Attach Filter
> >>>>
> >>>> not easy to do but should be extrem powerfull and flexible
> >>>> so on topic you dont need to choose a "prefered milter", just chain and
> >>>> combine all milters you like
> >>>
> >>> which makes much more sense thatn bending SA to do stuff it's not
> >>> designed to.
> >>>
> >>> IMO, deciding what chunk of a msg should be scanned should be managed by
> >>> the glue and not by SA.
> >>
> >> true but if the glue (spamass-milter) would truncate the message it
> >> passes to spamc it would get back that truncated message with the added
> >> headers (which are used to decide reject or pass) and so finally
> >> *deliver* the truncated version
> >
> > then spamass-milter is the wrong choice
>
> how else should it work?
>
> it hardly can invent the report-headers SA adds by itself which needs to
> land in the final message, spamc/spamd are doing the message work and
> the milter is just the glue to bring the MTA and SA together
>
No but, as others have suggested, if the glue shortens the message by
using MIME-aware code to remove binary attachments, it should be easy to
keep them while spamd scans the shortened message and then put them back
before the message is sent on downstream.
Martin
Re: Handling very large messages (was Re: Which milter do you prefer?)
Posted by Reindl Harald <h....@thelounge.net>.
Am 15.03.2015 um 19:15 schrieb Axb:
> On 03/15/2015 07:09 PM, Reindl Harald wrote:
>>
>> Am 15.03.2015 um 19:03 schrieb Axb:
>>> On 03/15/2015 06:49 PM, Robert Schetterer wrote:
>>>> Am 15.03.2015 um 18:32 schrieb Robert Schetterer:
>>>>> tagging is allowed, rejecting is nice but not a must have
>>>>
>>>> if you like reject try working in milter chaining with
>>>> milter-manager http://milter-manager.sourceforge.net/ ( stats
>>>> included )
>>>> this gives you option for complex filter scenarios with div milters
>>>> for size perhaps test combine with milter
>>>> milter-size
>>>> http://www.safe-mbox.com/~rgooch/email/index.html
>>>> and many other milter stuff i.e
>>>> https://www.milter.org/milter/98
>>>> MSH Attach Filter
>>>>
>>>> not easy to do but should be extrem powerfull and flexible
>>>> so on topic you dont need to choose a "prefered milter", just chain and
>>>> combine all milters you like
>>>
>>> which makes much more sense thatn bending SA to do stuff it's not
>>> designed to.
>>>
>>> IMO, deciding what chunk of a msg should be scanned should be managed by
>>> the glue and not by SA.
>>
>> true but if the glue (spamass-milter) would truncate the message it
>> passes to spamc it would get back that truncated message with the added
>> headers (which are used to decide reject or pass) and so finally
>> *deliver* the truncated version
>
> then spamass-milter is the wrong choice
how else should it work?
it hardly can invent the report-headers SA adds by itself which needs to
land in the final message, spamc/spamd are doing the message work and
the milter is just the glue to bring the MTA and SA together
Re: Handling very large messages (was Re: Which milter do you prefer?)
Posted by Axb <ax...@gmail.com>.
On 03/15/2015 07:09 PM, Reindl Harald wrote:
>
> Am 15.03.2015 um 19:03 schrieb Axb:
>> On 03/15/2015 06:49 PM, Robert Schetterer wrote:
>>> Am 15.03.2015 um 18:32 schrieb Robert Schetterer:
>>>> tagging is allowed, rejecting is nice but not a must have
>>>
>>> if you like reject try working in milter chaining with
>>> milter-manager http://milter-manager.sourceforge.net/ ( stats included )
>>> this gives you option for complex filter scenarios with div milters
>>> for size perhaps test combine with milter
>>> milter-size
>>> http://www.safe-mbox.com/~rgooch/email/index.html
>>> and many other milter stuff i.e
>>> https://www.milter.org/milter/98
>>> MSH Attach Filter
>>>
>>> not easy to do but should be extrem powerfull and flexible
>>> so on topic you dont need to choose a "prefered milter", just chain and
>>> combine all milters you like
>>
>> which makes much more sense thatn bending SA to do stuff it's not
>> designed to.
>>
>> IMO, deciding what chunk of a msg should be scanned should be managed by
>> the glue and not by SA.
>
> true but if the glue (spamass-milter) would truncate the message it
> passes to spamc it would get back that truncated message with the added
> headers (which are used to decide reject or pass) and so finally
> *deliver* the truncated version
then spamass-milter is the wrong choice.
Re: Handling very large messages (was Re: Which milter do you prefer?)
Posted by Reindl Harald <h....@thelounge.net>.
Am 15.03.2015 um 19:03 schrieb Axb:
> On 03/15/2015 06:49 PM, Robert Schetterer wrote:
>> Am 15.03.2015 um 18:32 schrieb Robert Schetterer:
>>> tagging is allowed, rejecting is nice but not a must have
>>
>> if you like reject try working in milter chaining with
>> milter-manager http://milter-manager.sourceforge.net/ ( stats included )
>> this gives you option for complex filter scenarios with div milters
>> for size perhaps test combine with milter
>> milter-size
>> http://www.safe-mbox.com/~rgooch/email/index.html
>> and many other milter stuff i.e
>> https://www.milter.org/milter/98
>> MSH Attach Filter
>>
>> not easy to do but should be extrem powerfull and flexible
>> so on topic you dont need to choose a "prefered milter", just chain and
>> combine all milters you like
>
> which makes much more sense thatn bending SA to do stuff it's not
> designed to.
>
> IMO, deciding what chunk of a msg should be scanned should be managed by
> the glue and not by SA.
true but if the glue (spamass-milter) would truncate the message it
passes to spamc it would get back that truncated message with the added
headers (which are used to decide reject or pass) and so finally
*deliver* the truncated version
Re: Handling very large messages (was Re: Which milter do you prefer?)
Posted by Axb <ax...@gmail.com>.
On 03/16/2015 10:16 AM, Reindl Harald wrote:
>
> Am 16.03.2015 um 03:43 schrieb Dave Warren:
>> On 2015-03-15 17:26, Reindl Harald wrote:
>>>
>>> Am 16.03.2015 um 01:23 schrieb Dave Warren:
>>>> On 2015-03-15 15:01, Reindl Harald wrote:
>>>>> surely, only 5% of incoming spam attempts make it to spamassassin /
>>>>> clamav here, but you need to keep in mind the amount of your regular
>>>>> ham messages in your mailflow which unconditionally touch the content
>>>>> scanners
>>>>
>>>> Why would it? I'd hazard a guess that, on a percentage basis, I run
>>>> less
>>>> ham though SpamAssassin than spam
>>>
>>> than your MTA filters *before* SA just don't work or you have very few
>>> legit mail at all
>>
>> Not at all, I just have comprehensive, adaptive, user-learned
>> whitelisting that catch the vast majority of legitimate mail before it
>> hits SpamAssassin. By whitelisting known-good sources aggressively and
>> automatically, I can cut the false positive rate to near zero, allowing
>> me to filter more aggressively at later stages.
>>
>>> 95% of any delivery attempt is blocked by a sensible
>>> DNSBL/DNSWL/PTR/HELO check on the MTA level and never makes it to
>>> milters at all
>>
>> SpamAssassin need only be responsible for sorting through mail that
>> isn't already known to be good or bad, putting known-good mail through
>> SpamAssassin is wasteful
>
> we are talking about milters and you can't bypass milters with postfix
> other than reject before but nor for whitelisting - period
yes you can *IF* they support using access tables
eg: milter-link
The action words supported by milter-link are:
OK White list, by-pass one or more tests.
REJECT Black list, reject connection, sender, recipient, etc.
SKIP Stop lookup and return no result ie. continue testing.
DUNNO Same as SKIP, commonly used by postfix.
as with all other Snertsoft's milters.
Re: Handling very large messages (was Re: Which milter do you prefer?)
Posted by Reindl Harald <h....@thelounge.net>.
Am 16.03.2015 um 03:43 schrieb Dave Warren:
> On 2015-03-15 17:26, Reindl Harald wrote:
>>
>> Am 16.03.2015 um 01:23 schrieb Dave Warren:
>>> On 2015-03-15 15:01, Reindl Harald wrote:
>>>> surely, only 5% of incoming spam attempts make it to spamassassin /
>>>> clamav here, but you need to keep in mind the amount of your regular
>>>> ham messages in your mailflow which unconditionally touch the content
>>>> scanners
>>>
>>> Why would it? I'd hazard a guess that, on a percentage basis, I run less
>>> ham though SpamAssassin than spam
>>
>> than your MTA filters *before* SA just don't work or you have very few
>> legit mail at all
>
> Not at all, I just have comprehensive, adaptive, user-learned
> whitelisting that catch the vast majority of legitimate mail before it
> hits SpamAssassin. By whitelisting known-good sources aggressively and
> automatically, I can cut the false positive rate to near zero, allowing
> me to filter more aggressively at later stages.
>
>> 95% of any delivery attempt is blocked by a sensible
>> DNSBL/DNSWL/PTR/HELO check on the MTA level and never makes it to
>> milters at all
>
> SpamAssassin need only be responsible for sorting through mail that
> isn't already known to be good or bad, putting known-good mail through
> SpamAssassin is wasteful
we are talking about milters and you can't bypass milters with postfix
other than reject before but nor for whitelisting - period
Re: Handling very large messages (was Re: Which milter do you prefer?)
Posted by Dave Warren <da...@hireahit.com>.
On 2015-03-15 17:26, Reindl Harald wrote:
>
> Am 16.03.2015 um 01:23 schrieb Dave Warren:
>> On 2015-03-15 15:01, Reindl Harald wrote:
>>> surely, only 5% of incoming spam attempts make it to spamassassin /
>>> clamav here, but you need to keep in mind the amount of your regular
>>> ham messages in your mailflow which unconditionally touch the content
>>> scanners
>>
>> Why would it? I'd hazard a guess that, on a percentage basis, I run less
>> ham though SpamAssassin than spam
>
> than your MTA filters *before* SA just don't work or you have very few
> legit mail at all
>
Not at all, I just have comprehensive, adaptive, user-learned
whitelisting that catch the vast majority of legitimate mail before it
hits SpamAssassin. By whitelisting known-good sources aggressively and
automatically, I can cut the false positive rate to near zero, allowing
me to filter more aggressively at later stages.
> 95% of any delivery attempt is blocked by a sensible
> DNSBL/DNSWL/PTR/HELO check on the MTA level and never makes it to
> milters at all
SpamAssassin need only be responsible for sorting through mail that
isn't already known to be good or bad, putting known-good mail through
SpamAssassin is wasteful.
--
Dave Warren
http://www.hireahit.com/
http://ca.linkedin.com/in/davejwarren
Re: Handling very large messages (was Re: Which milter do you prefer?)
Posted by Reindl Harald <h....@thelounge.net>.
Am 16.03.2015 um 01:23 schrieb Dave Warren:
> On 2015-03-15 15:01, Reindl Harald wrote:
>> surely, only 5% of incoming spam attempts make it to spamassassin /
>> clamav here, but you need to keep in mind the amount of your regular
>> ham messages in your mailflow which unconditionally touch the content
>> scanners
>
> Why would it? I'd hazard a guess that, on a percentage basis, I run less
> ham though SpamAssassin than spam
than your MTA filters *before* SA just don't work or you have very few
legit mail at all
95% of any delivery attempt is blocked by a sensible
DNSBL/DNSWL/PTR/HELO check on the MTA level and never makes it to
milters at all
Re: Handling very large messages (was Re: Which milter do you prefer?)
Posted by Dave Warren <da...@hireahit.com>.
On 2015-03-15 15:01, Reindl Harald wrote:
> surely, only 5% of incoming spam attempts make it to spamassassin /
> clamav here, but you need to keep in mind the amount of your regular
> ham messages in your mailflow which unconditionally touch the content
> scanners
Why would it? I'd hazard a guess that, on a percentage basis, I run less
ham though SpamAssassin than spam.
Obviously comparing the raw numbers will give a different reset of
results, due to the drastically different number of spam attempts vs ham
attempts.
--
Dave Warren
http://www.hireahit.com/
http://ca.linkedin.com/in/davejwarren
Re: Handling very large messages (was Re: Which milter do you prefer?)
Posted by Reindl Harald <h....@thelounge.net>.
Am 15.03.2015 um 22:19 schrieb Robert Schetterer:
> hypothetical...
>
> spam tagging by spamassassin is "expensive" by design so it should be
> the last step in a long chain of different "antispam" features mostly
> i.e postscreen, clamav-milter, greylisting, rbl filtering, spf dkim
> dmarc checks
surely, only 5% of incoming spam attempts make it to spamassassin /
clamav here, but you need to keep in mind the amount of your regular ham
messages in your mailflow which unconditionally touch the content scanners
hence optimizing the ressource usage of the content filter makes in any
case sense
having clamav-milter before spamass-milter in theory is a good idea
because clamav is much faster, in the real world the problem is that it
only rejects a small amount of junk and having spamass-milter before
clamav reduces the load because it bypasses the next layer - here too:
your ham mail makes it through both layers anyways
a few months ago after looking at the real mail flow clamav-milter was
ordered here after spamass-milter since it only rejected 1% of the junk
making it throgh milters at all while SA rejects 10% of the complete
mail flow
> Speculation... big spam mails sourced by hacked big mail providers accounts
> are perhaps most difficult to catch ( cause they pass spf dkim etc
> checks before )
>
> So an idea might be switch those providers in another scan chain as
> other mails by milter-manager conditions, you might use multiple
> instances of spamass-milter and/or spamassassin with different setups.
> Multiple other "switches" may integrated with other milters features
>
> For sure such stuff has to be checked against real world examples
> an log analysis. At the end this should give most flexible chances to
> goal multiple scenarios
which makes the setup more complex and difficult to maintain
even if you go that road - performance optimizing inside SA would
improve *both* chains
Re: Handling very large messages (was Re: Which milter do you prefer?)
Posted by Robert Schetterer <rs...@sys4.de>.
Am 15.03.2015 um 19:03 schrieb Axb:
> On 03/15/2015 06:49 PM, Robert Schetterer wrote:
>> Am 15.03.2015 um 18:32 schrieb Robert Schetterer:
>>> tagging is allowed, rejecting is nice but not a must have
>>
>> if you like reject try working in milter chaining with
>> milter-manager http://milter-manager.sourceforge.net/ ( stats included )
>> this gives you option for complex filter scenarios with div milters
>> for size perhaps test combine with milter
>> milter-size
>> http://www.safe-mbox.com/~rgooch/email/index.html
>> and many other milter stuff i.e
>> https://www.milter.org/milter/98
>> MSH Attach Filter
>>
>> not easy to do but should be extrem powerfull and flexible
>> so on topic you dont need to choose a "prefered milter", just chain and
>> combine all milters you like
>
> which makes much more sense thatn bending SA to do stuff it's not
> designed to.
>
> IMO, deciding what chunk of a msg should be scanned should be managed by
> the glue and not by SA.
>
hypothetical...
spam tagging by spamassassin is "expensive" by design so it should be
the last step in a long chain of different "antispam" features mostly
i.e postscreen, clamav-milter, greylisting, rbl filtering, spf dkim
dmarc checks
Speculation... big spam mails sourced by hacked big mail providers accounts
are perhaps most difficult to catch ( cause they pass spf dkim etc
checks before )
So an idea might be switch those providers in another scan chain as
other mails by milter-manager conditions, you might use multiple
instances of spamass-milter and/or spamassassin with different setups.
Multiple other "switches" may integrated with other milters features
For sure such stuff has to be checked against real world examples
an log analysis. At the end this should give most flexible chances to
goal multiple scenarios.
Best Regards
MfG Robert Schetterer
--
[*] sys4 AG
http://sys4.de, +49 (89) 30 90 46 64
Franziskanerstraße 15, 81669 München
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein
Re: Handling very large messages (was Re: Which milter do you prefer?)
Posted by Axb <ax...@gmail.com>.
On 03/15/2015 06:49 PM, Robert Schetterer wrote:
> Am 15.03.2015 um 18:32 schrieb Robert Schetterer:
>> tagging is allowed, rejecting is nice but not a must have
>
> if you like reject try working in milter chaining with
> milter-manager http://milter-manager.sourceforge.net/ ( stats included )
> this gives you option for complex filter scenarios with div milters
> for size perhaps test combine with milter
> milter-size
> http://www.safe-mbox.com/~rgooch/email/index.html
> and many other milter stuff i.e
> https://www.milter.org/milter/98
> MSH Attach Filter
>
> not easy to do but should be extrem powerfull and flexible
> so on topic you dont need to choose a "prefered milter", just chain and
> combine all milters you like
which makes much more sense thatn bending SA to do stuff it's not
designed to.
IMO, deciding what chunk of a msg should be scanned should be managed by
the glue and not by SA.
Re: Handling very large messages (was Re: Which milter do you prefer?)
Posted by Robert Schetterer <rs...@sys4.de>.
Am 15.03.2015 um 18:32 schrieb Robert Schetterer:
> tagging is allowed, rejecting is nice but not a must have
if you like reject try working in milter chaining with
milter-manager http://milter-manager.sourceforge.net/ ( stats included )
this gives you option for complex filter scenarios with div milters
for size perhaps test combine with milter
milter-size
http://www.safe-mbox.com/~rgooch/email/index.html
and many other milter stuff i.e
https://www.milter.org/milter/98
MSH Attach Filter
not easy to do but should be extrem powerfull and flexible
so on topic you dont need to choose a "prefered milter", just chain and
combine all milters you like
Best Regards
MfG Robert Schetterer
--
[*] sys4 AG
http://sys4.de, +49 (89) 30 90 46 64
Franziskanerstraße 15, 81669 München
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein
Re: Handling very large messages (was Re: Which milter do you prefer?)
Posted by Robert Schetterer <rs...@sys4.de>.
Am 15.03.2015 um 17:53 schrieb Reindl Harald:
>
> Am 15.03.2015 um 17:24 schrieb Robert Schetterer:
>> Am 15.03.2015 um 12:05 schrieb Reindl Harald:
>>>
>>> Am 14.03.2015 um 20:17 schrieb Robert Schetterer:
>>>> Am 14.03.2015 um 18:11 schrieb Reindl Harald:
>>>>> nobody but talks about cut content
>>>>>
>>>>> we talk about how to pass only a part to spamassassin instead skip
>>>>> large
>>>>> messages entirely which in many case would be enough to detect a
>>>>> message
>>>>> as spam because the "oversize" are just binary parts
>>>>
>>>> Ok, but big spam mails are extrem rare, i wouldnt invest time in that
>>>
>>> you are so terrible wrong
>>
>> my intention was never to agree with you
>
> so what....
>
>>> more and more spam messages are coming with a very large image because
>>> spammers know the default 256 KB limit which also affects commercial
>>> products like from Barracuda Networks, that is not a new trend
>>>
>>> there is a reason for "-s 5242880" in our setup while i started with "-s
>>> 786432" a few months ago
>>>
>>
>> as i wrote this may happen at your site, you should not set your
>> experience as ultimate
>
> but you did that with "Ok, but big spam mails are extrem rare"
and wrote "i" wouldnt invest time in this, nice if you will do it
>
>> everyone has his/its own spam, i dont see any rise in large mail spam
>> here
>
> that may be true for *your* account but hardly in case of a large
> user-base for all users, you just don't notice the bypassed junk
10000 users dont reported to fix it yet
i dont work in building a perfect world
>
>> back to topic i would recommend a two stage spam filtering, if you got
>> in trouble with "big spam mail", i.e spamass-milter in front line, then
>> "perhaps" combine sieve filters with size/spam matches etc
>
> that can't work beause at that stage you already received the message
> instead reject it and so can't discard it without backscattering
>
tagging is allowed, rejecting is nice but not a must have
Best Regards
MfG Robert Schetterer
--
[*] sys4 AG
http://sys4.de, +49 (89) 30 90 46 64
Franziskanerstraße 15, 81669 München
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein
Re: Handling very large messages (was Re: Which milter do you prefer?)
Posted by Reindl Harald <h....@thelounge.net>.
Am 15.03.2015 um 17:24 schrieb Robert Schetterer:
> Am 15.03.2015 um 12:05 schrieb Reindl Harald:
>>
>> Am 14.03.2015 um 20:17 schrieb Robert Schetterer:
>>> Am 14.03.2015 um 18:11 schrieb Reindl Harald:
>>>> nobody but talks about cut content
>>>>
>>>> we talk about how to pass only a part to spamassassin instead skip large
>>>> messages entirely which in many case would be enough to detect a message
>>>> as spam because the "oversize" are just binary parts
>>>
>>> Ok, but big spam mails are extrem rare, i wouldnt invest time in that
>>
>> you are so terrible wrong
>
> my intention was never to agree with you
so what....
>> more and more spam messages are coming with a very large image because
>> spammers know the default 256 KB limit which also affects commercial
>> products like from Barracuda Networks, that is not a new trend
>>
>> there is a reason for "-s 5242880" in our setup while i started with "-s
>> 786432" a few months ago
>>
>
> as i wrote this may happen at your site, you should not set your
> experience as ultimate
but you did that with "Ok, but big spam mails are extrem rare"
> everyone has his/its own spam, i dont see any rise in large mail spam here
that may be true for *your* account but hardly in case of a large
user-base for all users, you just don't notice the bypassed junk
> back to topic i would recommend a two stage spam filtering, if you got
> in trouble with "big spam mail", i.e spamass-milter in front line, then
> "perhaps" combine sieve filters with size/spam matches etc
that can't work beause at that stage you already received the message
instead reject it and so can't discard it without backscattering
Re: Handling very large messages (was Re: Which milter do you prefer?)
Posted by Robert Schetterer <rs...@sys4.de>.
Am 15.03.2015 um 12:05 schrieb Reindl Harald:
>
> Am 14.03.2015 um 20:17 schrieb Robert Schetterer:
>> Am 14.03.2015 um 18:11 schrieb Reindl Harald:
>>> nobody but talks about cut content
>>>
>>> we talk about how to pass only a part to spamassassin instead skip large
>>> messages entirely which in many case would be enough to detect a message
>>> as spam because the "oversize" are just binary parts
>>
>> Ok, but big spam mails are extrem rare, i wouldnt invest time in that
>
> you are so terrible wrong
my intention was never to agree with you
>
> more and more spam messages are coming with a very large image because
> spammers know the default 256 KB limit which also affects commercial
> products like from Barracuda Networks, that is not a new trend
>
> there is a reason for "-s 5242880" in our setup while i started with "-s
> 786432" a few months ago
>
as i wrote this may happen at your site, you should not set your
experience as ultimate
everyone has his/its own spam, i dont see any rise in large mail spam here
back to topic i would recommend a two stage spam filtering, if you got
in trouble with "big spam mail", i.e spamass-milter in front line, then
"perhaps" combine sieve filters with size/spam matches etc
Best Regards
MfG Robert Schetterer
--
[*] sys4 AG
http://sys4.de, +49 (89) 30 90 46 64
Franziskanerstraße 15, 81669 München
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein
Re: Handling very large messages (was Re: Which milter do you prefer?)
Posted by Reindl Harald <h....@thelounge.net>.
Am 14.03.2015 um 20:17 schrieb Robert Schetterer:
> Am 14.03.2015 um 18:11 schrieb Reindl Harald:
>> nobody but talks about cut content
>>
>> we talk about how to pass only a part to spamassassin instead skip large
>> messages entirely which in many case would be enough to detect a message
>> as spam because the "oversize" are just binary parts
>
> Ok, but big spam mails are extrem rare, i wouldnt invest time in that
you are so terrible wrong
more and more spam messages are coming with a very large image because
spammers know the default 256 KB limit which also affects commercial
products like from Barracuda Networks, that is not a new trend
there is a reason for "-s 5242880" in our setup while i started with "-s
786432" a few months ago
Re: Handling very large messages (was Re: Which milter do you
prefer?)
Posted by "David F. Skoll" <df...@roaringpenguin.com>.
On Sat, 14 Mar 2015 20:45:16 +0100
Robert Schetterer <rs...@sys4.de> wrote:
> In the last ten years i saw a handfull of these, but ok, perhaps
> different at your site.
Mostly they're spams with the payload in a PDF document, a Word
document or an image. Very occasionally, we see ones where the plain-text
is padded to a couple of megabytes, but those are extremely rare.
We filter mail for quite a lot of people, so we do see even quite rare
events.
Regards,
David.
Re: Handling very large messages (was Re: Which milter do you prefer?)
Posted by Nick Edwards <ni...@gmail.com>.
On 3/15/15, Robert Schetterer <rs...@sys4.de> wrote:
> Am 14.03.2015 um 20:22 schrieb David F. Skoll:
>> On Sat, 14 Mar 2015 20:17:27 +0100
>> Robert Schetterer <rs...@sys4.de> wrote:
>>
>>> Ok, but big spam mails are extrem rare, i wouldnt invest time in that
>>
>> They are quite rare, but common enough IMO that our customers would be
>> annoyed if we didn't scan them.
>>
>> Regards,
>>
>> David.
>>
>
> In the last ten years i saw a handfull of these, but ok, perhaps
> different at your site.
>
>
>
> Best Regards
> MfG Robert Schetterer
>
> --
> [*] sys4 AG
>
> http://sys4.de, +49 (89) 30 90 46 64
> Franziskanerstraße 15, 81669 München
>
> Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
> Vorstand: Patrick Ben Koetter, Marc Schiffbauer
> Aufsichtsratsvorsitzender: Florian Kirstein
>
I think we too would know if large spam were a problem and our users
active email count is fair size, not huge, but not small
mysql> select count(*) from users where active='1';
+----------+
| count(*) |
+----------+
| 3801914 |
+----------+
1 row in set (0.00 sec)
and we have some bitchy customers that make reindl look like a sunday
school kid.
Re: Handling very large messages (was Re: Which milter do you prefer?)
Posted by Robert Schetterer <rs...@sys4.de>.
Am 14.03.2015 um 20:22 schrieb David F. Skoll:
> On Sat, 14 Mar 2015 20:17:27 +0100
> Robert Schetterer <rs...@sys4.de> wrote:
>
>> Ok, but big spam mails are extrem rare, i wouldnt invest time in that
>
> They are quite rare, but common enough IMO that our customers would be
> annoyed if we didn't scan them.
>
> Regards,
>
> David.
>
In the last ten years i saw a handfull of these, but ok, perhaps
different at your site.
Best Regards
MfG Robert Schetterer
--
[*] sys4 AG
http://sys4.de, +49 (89) 30 90 46 64
Franziskanerstraße 15, 81669 München
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein
Re: Handling very large messages (was Re: Which milter do you
prefer?)
Posted by "David F. Skoll" <df...@roaringpenguin.com>.
On Sat, 14 Mar 2015 20:17:27 +0100
Robert Schetterer <rs...@sys4.de> wrote:
> Ok, but big spam mails are extrem rare, i wouldnt invest time in that
They are quite rare, but common enough IMO that our customers would be
annoyed if we didn't scan them.
Regards,
David.
Re: Handling very large messages (was Re: Which milter do you
prefer?)
Posted by Bill Cole <sa...@billmail.scconsult.com>.
On 14 Mar 2015, at 15:17, Robert Schetterer wrote:
[...]
>>> Am 14.03.2015 um 17:55 schrieb David F. Skoll:
[...]
>>>> I can't answer for Kevin, but what we do is this: For oversize
>>>> messages, we remove non text/* attachments. If they're still
>>>> oversize, we truncate the text/plain parts. If they're still
>>>> oversize, we truncate the text/html parts. We do this very
>>>> carefully
>>>> with MIME::tools to ensure that SpamAssassin always sees a valid
>>>> MIME
>>>> message and not (for example) one with a missing boundary.
>>>>
>>>> We use MIMEDefang for SpamAssassin integration, so we can play
>>>> whatever
>>>> tricks we like with the data that gets passed to SpamAssassin
>>>> without
>>>> actually messing with the original message.
[...]
> Ok, but big spam mails are extrem rare, i wouldnt invest time in that
Not true in all contexts.
The majority of user-reported uncaught spam messages on a system I
manage in the past 6 months are ones that have bypassed SA filtering
because they were oversize. I've actually invested some time in
mitigating this problem because users want a fix more than they want
anything else about spam-filtering changed on that system. Despite using
MD I had not thought of David's approach, instead I have used less
scalable approaches of enforcing other rules on large mail that suit the
system in question (e.g. varying hard limits on message size based on
sender domain.) I now intend to supplement that with selective MIME
dismemberment ahead of filtering.
Re: Handling very large messages (was Re: Which milter do you prefer?)
Posted by Robert Schetterer <rs...@sys4.de>.
Am 14.03.2015 um 18:11 schrieb Reindl Harald:
>
>
> Am 14.03.2015 um 18:01 schrieb Robert Schetterer:
>> Am 14.03.2015 um 17:55 schrieb David F. Skoll:
>>> On Sat, 14 Mar 2015 17:08:50 +0100
>>> Reindl Harald <h....@thelounge.net> wrote:
>>>
>>>> Am 14.03.2015 um 17:00 schrieb Kevin A. McGrail:
>>>>> On 3/14/2015 1:14 AM, David B Funk wrote:
>>>>>> truncating a large message and
>>>>>> only passing the first N-KB to SA. As that involves munging MIME
>>>>>> headers it has to be done inside the milter.
>>>>>>
>>>>> I just truncate the message hard and it generally works better than
>>>>> not scanning. What do you do to truncate?
>>>
>>>> how do you truncate messages for the scan?
>>>
>>> I can't answer for Kevin, but what we do is this: For oversize
>>> messages, we remove non text/* attachments. If they're still
>>> oversize, we truncate the text/plain parts. If they're still
>>> oversize, we truncate the text/html parts. We do this very carefully
>>> with MIME::tools to ensure that SpamAssassin always sees a valid MIME
>>> message and not (for example) one with a missing boundary.
>>>
>>> We use MIMEDefang for SpamAssassin integration, so we can play whatever
>>> tricks we like with the data that gets passed to SpamAssassin without
>>> actually messing with the original message.
>>>
>> define oversize..., cutting mail content may not allowed in many
>> countries, most legal policy, is reject ( at income smtp level ) or pass
>> tag passed mail is allowed if the reciept accepts this
>
> nobody but talks about cut content
>
> we talk about how to pass only a part to spamassassin instead skip large
> messages entirely which in many case would be enough to detect a message
> as spam because the "oversize" are just binary parts
>
Ok, but big spam mails are extrem rare, i wouldnt invest time in that
Best Regards
MfG Robert Schetterer
--
[*] sys4 AG
http://sys4.de, +49 (89) 30 90 46 64
Franziskanerstraße 15, 81669 München
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein
Re: Handling very large messages (was Re: Which milter do you prefer?)
Posted by Reindl Harald <h....@thelounge.net>.
Am 14.03.2015 um 18:01 schrieb Robert Schetterer:
> Am 14.03.2015 um 17:55 schrieb David F. Skoll:
>> On Sat, 14 Mar 2015 17:08:50 +0100
>> Reindl Harald <h....@thelounge.net> wrote:
>>
>>> Am 14.03.2015 um 17:00 schrieb Kevin A. McGrail:
>>>> On 3/14/2015 1:14 AM, David B Funk wrote:
>>>>> truncating a large message and
>>>>> only passing the first N-KB to SA. As that involves munging MIME
>>>>> headers it has to be done inside the milter.
>>>>>
>>>> I just truncate the message hard and it generally works better than
>>>> not scanning. What do you do to truncate?
>>
>>> how do you truncate messages for the scan?
>>
>> I can't answer for Kevin, but what we do is this: For oversize
>> messages, we remove non text/* attachments. If they're still
>> oversize, we truncate the text/plain parts. If they're still
>> oversize, we truncate the text/html parts. We do this very carefully
>> with MIME::tools to ensure that SpamAssassin always sees a valid MIME
>> message and not (for example) one with a missing boundary.
>>
>> We use MIMEDefang for SpamAssassin integration, so we can play whatever
>> tricks we like with the data that gets passed to SpamAssassin without
>> actually messing with the original message.
>>
> define oversize..., cutting mail content may not allowed in many
> countries, most legal policy, is reject ( at income smtp level ) or pass
> tag passed mail is allowed if the reciept accepts this
nobody but talks about cut content
we talk about how to pass only a part to spamassassin instead skip large
messages entirely which in many case would be enough to detect a message
as spam because the "oversize" are just binary parts
Re: Handling very large messages (was Re: Which milter do you
prefer?)
Posted by "David F. Skoll" <df...@roaringpenguin.com>.
On Sat, 14 Mar 2015 18:01:10 +0100
Robert Schetterer <rs...@sys4.de> wrote:
> define oversize...,
It's configurable, obviously.
> cutting mail content may not allowed in many countries,
Ummm... WTF? We cut what we pass to SpamAssassin. We don't actually
alter the original message. That is either accepted, rejected or
quarantined depending on filtering results.
Regards,
David.
Re: Handling very large messages (was Re: Which milter do you prefer?)
Posted by "Kevin A. McGrail" <KM...@PCCC.com>.
On 3/14/2015 1:01 PM, Robert Schetterer wrote:
> define oversize..., cutting mail content may not allowed in many
> countries, most legal policy, is reject ( at income smtp level ) or pass
> , tag passed mail is allowed if the reciept accepts this
We are talking about modifying a stateful copy of the email which is
used only for email classification testing.
regards,
KAM
Re: Handling very large messages (was Re: Which milter do you prefer?)
Posted by Robert Schetterer <rs...@sys4.de>.
Am 14.03.2015 um 17:55 schrieb David F. Skoll:
> On Sat, 14 Mar 2015 17:08:50 +0100
> Reindl Harald <h....@thelounge.net> wrote:
>
>> Am 14.03.2015 um 17:00 schrieb Kevin A. McGrail:
>>> On 3/14/2015 1:14 AM, David B Funk wrote:
>>>> truncating a large message and
>>>> only passing the first N-KB to SA. As that involves munging MIME
>>>> headers it has to be done inside the milter.
>>>>
>>> I just truncate the message hard and it generally works better than
>>> not scanning. What do you do to truncate?
>
>> how do you truncate messages for the scan?
>
> I can't answer for Kevin, but what we do is this: For oversize
> messages, we remove non text/* attachments. If they're still
> oversize, we truncate the text/plain parts. If they're still
> oversize, we truncate the text/html parts. We do this very carefully
> with MIME::tools to ensure that SpamAssassin always sees a valid MIME
> message and not (for example) one with a missing boundary.
>
> We use MIMEDefang for SpamAssassin integration, so we can play whatever
> tricks we like with the data that gets passed to SpamAssassin without
> actually messing with the original message.
>
> Regards,
>
> David.
>
define oversize..., cutting mail content may not allowed in many
countries, most legal policy, is reject ( at income smtp level ) or pass
, tag passed mail is allowed if the reciept accepts this
Best Regards
MfG Robert Schetterer
--
[*] sys4 AG
http://sys4.de, +49 (89) 30 90 46 64
Franziskanerstraße 15, 81669 München
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein
Handling very large messages (was Re: Which milter do you prefer?)
Posted by "David F. Skoll" <df...@roaringpenguin.com>.
On Sat, 14 Mar 2015 17:08:50 +0100
Reindl Harald <h....@thelounge.net> wrote:
> Am 14.03.2015 um 17:00 schrieb Kevin A. McGrail:
> > On 3/14/2015 1:14 AM, David B Funk wrote:
> >> truncating a large message and
> >> only passing the first N-KB to SA. As that involves munging MIME
> >> headers it has to be done inside the milter.
> >>
> > I just truncate the message hard and it generally works better than
> > not scanning. What do you do to truncate?
> how do you truncate messages for the scan?
I can't answer for Kevin, but what we do is this: For oversize
messages, we remove non text/* attachments. If they're still
oversize, we truncate the text/plain parts. If they're still
oversize, we truncate the text/html parts. We do this very carefully
with MIME::tools to ensure that SpamAssassin always sees a valid MIME
message and not (for example) one with a missing boundary.
We use MIMEDefang for SpamAssassin integration, so we can play whatever
tricks we like with the data that gets passed to SpamAssassin without
actually messing with the original message.
Regards,
David.
Re: Which milter do you prefer?
Posted by Reindl Harald <h....@thelounge.net>.
Am 14.03.2015 um 17:00 schrieb Kevin A. McGrail:
> On 3/14/2015 1:14 AM, David B Funk wrote:
>> truncating a large message and
>> only passing the first N-KB to SA. As that involves munging MIME headers
>> it has to be done inside the milter.
>>
> I just truncate the message hard and it generally works better than not
> scanning. What do you do to truncate?
how do you truncate messages for the scan?
as far as i understand the process milter hands over the mail to spamc
and get back the modified message (report headers and so on) which is
then passed to the users inbox which forbids truncate the message at
that stage
according to this spamd would need to stop processing after X bytes but
get the full message and bounce it back to the milter untruncated
Re: Which milter do you prefer?
Posted by "Kevin A. McGrail" <KM...@PCCC.com>.
On 3/14/2015 1:14 AM, David B Funk wrote:
> truncating a large message and
> only passing the first N-KB to SA. As that involves munging MIME headers
> it has to be done inside the milter.
>
I just truncate the message hard and it generally works better than not
scanning. What do you do to truncate?
Regards,
KAM
Re: Which milter do you prefer?
Posted by David B Funk <db...@engineering.uiowa.edu>.
On Fri, 13 Mar 2015, @lbutlr wrote:
> On 13 Mar 2015, at 17:54 , Greg Troxel <gd...@ir.bbn.com> wrote:
>> Currently I'm using spamass-milter, which seems to have been teetering
>> on the edge of unmaintained, although the 0.4.0 release on 2014-09-11
>> staved that off for a while. Note that the previous release was
>> 2006-04-05
>
> I’m not sure how important it is that it seem frequent updates. It’s really just a conduit between spamassassin and sendmail. I wouldn’t think it would need much in the way of development, the work is all on the other ends.
Maybe not frequent updates but both the sendmail milter protocol and the
spamd protocol have seen changes which should be incorporated in the milter.
The spam landscape has changed which can trigger the need for changes in the
milter; EG originally my milter just punted on any oversized message and gave
it a pass. As spammers started tacking on large images/PDFs/DOCs etc on the
end of their spam they quickly grew to a size larger than what you'd want to
try to feed to SA. So I responed to that by truncating a large message and
only passing the first N-KB to SA. As that involves munging MIME headers
it has to be done inside the milter.
Long story short, when I first got miltrassassin 12 years ago it was ~900
lines, it's now more than double that size. Some of that was bug fixes,
porting to new platforms, etc but most was adding features I wanted.
--
Dave Funk University of Iowa
<dbfunk (at) engineering.uiowa.edu> College of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center
Sys_admin/Postmaster/cell_admin Iowa City, IA 52242-1527
#include <std_disclaimer.h>
Better is not better, 'standard' is better. B{
Re: Which milter do you prefer?
Posted by "@lbutlr" <kr...@kreme.com>.
On 13 Mar 2015, at 17:54 , Greg Troxel <gd...@ir.bbn.com> wrote:
> Currently I'm using spamass-milter, which seems to have been teetering
> on the edge of unmaintained, although the 0.4.0 release on 2014-09-11
> staved that off for a while. Note that the previous release was
> 2006-04-05
I’m not sure how important it is that it seem frequent updates. It’s really just a conduit between spamassassin and sendmail. I wouldn’t think it would need much in the way of development, the work is all on the other ends.
--
Matters in hand. He'd put matters in hand all right. If he closed his
eyes he could see the body tumbling down the steps. Had there been a
hiss of shocked breath, down in the darkness of the hall? He'd been
certain they were alone. Matters in hand! He'd tried to wash the blood
off his hands. If he could wash the blood off, he told himself, it
wouldn't have happened. He'd scrubbed and scrubbed. Scrubbed till he
screamed. --Wyrd Sisters
Re: Which milter do you prefer?
Posted by Greg Troxel <gd...@ir.bbn.com>.
Shane Williams <sh...@shanew.net> writes:
> It seems like spamass-milter is the default go-to for most people, but
> I'd really like one that can listen on an INET socket (and
> spamass-milter doesn't as far as I can tell, but please correct me if
> I'm wrong). Milter-spamc from SnertSoft looks promising, but it's not
> free, and a bit more complicated. smtp-vilter also looks interesting,
> but it does more than just SpamAssassin stuff, so might be overkill.
>
> And I suspect there are a bunch more out there (though a lot of these
> projects seem to have stalled or died over time).
>
> What are your favorite (not spamass-milter) options for plugging
> spamassassin into a milter?
Currently I'm using spamass-milter, which seems to have been teetering
on the edge of unmaintained, although the 0.4.0 release on 2014-09-11
staved that off for a while. Note that the previous release was
2006-04-05.
I am currently looking at mopher, which integrates spamassassin and
greylisting:
http://mopher.org/
Re: Which milter do you prefer?
Posted by Axb <ax...@gmail.com>.
On 03/13/2015 11:35 PM, shanew@shanew.net wrote:
> Well, you don't have to try very hard to start a holy war around here
> ;-) Seriously, though, I wasn't thinking at the level of amavisd,
> mimedefang, or mailscanner.
>
> Those may come later, but the situation I'm in right this moment is
> that I'm taking over a very idiosyncratic mail environment, and I need
> to tune and monitor it's performance before switching over. Thus, the
> least disruptive option I see is to insert a milter for spamassassin
> in front of anything else, and then score / log messages without
> tampering with them in anyway, so they can continue through the milter
> chain as if it weren't even there (except for some slight delay).
> Spamass-milter does this, but it means running the milter on the
> existing system rather than just pointing sendmail to a remote
> milter. I may end up there anyhow, but I thought I'd ask first.
>
> All this, of course, after searching high and low for a milter, proxy,
> or some other contraption that would allow me to "clone" a mail stream
> to a totally separate server without disrupting the original stream
> (like port spanning or a network tap, but for SMTP), and finding
> nothing outside of alpha or beta to do that. If anyone knows of
> something like that, I'd be interested to hear about it as well.
As this doesn't feel like your personaly mail server, I would advise you
against cloning production traffic in transit. If something goes wrong
in the clone... yuk.
Re: Which milter do you prefer?
Posted by "David F. Skoll" <df...@roaringpenguin.com>.
On Fri, 13 Mar 2015 17:35:34 -0500 (CDT)
shanew@shanew.net wrote:
> All this, of course, after searching high and low for a milter, proxy,
> or some other contraption that would allow me to "clone" a mail stream
> to a totally separate server without disrupting the original stream
> (like port spanning or a network tap, but for SMTP), and finding
> nothing outside of alpha or beta to do that. If anyone knows of
> something like that, I'd be interested to hear about it as well.
That can have... interesting failure modes if the cloned stream and
the original stream encounter different SMTP reply codes.
MIMEDefang can do what you want in about 5 lines of Perl. I believe
there's also a dedicated tool that does this called Roundhouse:
http://www.snertsoft.com/sendmail/roundhouse/
Note that Roundhouse is not free software.
Regards,
David.
Re: Which milter do you prefer?
Posted by sh...@shanew.net.
I just came across that in my searching yesterday, but hadn't had a
chance to dig deeper. I had seen roundhouse, and a few other things
here and there, but they all seemed lacking. After all, as others
have mentioned, cloning your mail stream is not to be done lightly.
On Fri, 13 Mar 2015, Ted Mittelstaedt wrote:
> All this, of course, after searching high and low for a milter, proxy,
>> or some other contraption that would allow me to "clone" a mail stream
>> to a totally separate server without disrupting the original stream
>> (like port spanning or a network tap, but for SMTP),
>
>
> Need a better Search Engine, what you want is here:
>
> http://www.dv8.ro/Synonym/synonym.html
>
> Throw that Bing crap in the trash. ;-)
>
> Ted
>
> On 3/13/2015 3:35 PM, shanew@shanew.net wrote:
>> Well, you don't have to try very hard to start a holy war around here
>> ;-) Seriously, though, I wasn't thinking at the level of amavisd,
>> mimedefang, or mailscanner.
>>
>> Those may come later, but the situation I'm in right this moment is
>> that I'm taking over a very idiosyncratic mail environment, and I need
>> to tune and monitor it's performance before switching over. Thus, the
>> least disruptive option I see is to insert a milter for spamassassin
>> in front of anything else, and then score / log messages without
>> tampering with them in anyway, so they can continue through the milter
>> chain as if it weren't even there (except for some slight delay).
>> Spamass-milter does this, but it means running the milter on the
>> existing system rather than just pointing sendmail to a remote
>> milter. I may end up there anyhow, but I thought I'd ask first.
>>
>> All this, of course, after searching high and low for a milter, proxy,
>> or some other contraption that would allow me to "clone" a mail stream
>> to a totally separate server without disrupting the original stream
>> (like port spanning or a network tap, but for SMTP), and finding
>> nothing outside of alpha or beta to do that. If anyone knows of
>> something like that, I'd be interested to hear about it as well.
>>
>> On Fri, 13 Mar 2015, Kevin A. McGrail wrote:
>>
>> > On 3/13/2015 5:41 PM, Shane Williams wrote:
>> > > What are your favorite (not spamass-milter) options for plugging
>> > > spamassassin into a milter?
>> >
>> > Trying to start a holy-war on the list? ;-)
>> >
>> > +1 for MIMEDefang.
>> >
>> > Regards,
>> > KAM
>> >
>> >
>>
>
>
--
Public key #7BBC68D9 at | Shane Williams
http://pgp.mit.edu/ | System Admin - UT CompSci
=----------------------------------+-------------------------------
All syllogisms contain three lines | shanew@shanew.net
Therefore this is not a syllogism | www.ischool.utexas.edu/~shanew
Re: Which milter do you prefer?
Posted by Ted Mittelstaedt <te...@ipinc.net>.
All this, of course, after searching high and low for a milter, proxy,
> or some other contraption that would allow me to "clone" a mail stream
> to a totally separate server without disrupting the original stream
> (like port spanning or a network tap, but for SMTP),
Need a better Search Engine, what you want is here:
http://www.dv8.ro/Synonym/synonym.html
Throw that Bing crap in the trash. ;-)
Ted
On 3/13/2015 3:35 PM, shanew@shanew.net wrote:
> Well, you don't have to try very hard to start a holy war around here
> ;-) Seriously, though, I wasn't thinking at the level of amavisd,
> mimedefang, or mailscanner.
>
> Those may come later, but the situation I'm in right this moment is
> that I'm taking over a very idiosyncratic mail environment, and I need
> to tune and monitor it's performance before switching over. Thus, the
> least disruptive option I see is to insert a milter for spamassassin
> in front of anything else, and then score / log messages without
> tampering with them in anyway, so they can continue through the milter
> chain as if it weren't even there (except for some slight delay).
> Spamass-milter does this, but it means running the milter on the
> existing system rather than just pointing sendmail to a remote
> milter. I may end up there anyhow, but I thought I'd ask first.
>
> All this, of course, after searching high and low for a milter, proxy,
> or some other contraption that would allow me to "clone" a mail stream
> to a totally separate server without disrupting the original stream
> (like port spanning or a network tap, but for SMTP), and finding
> nothing outside of alpha or beta to do that. If anyone knows of
> something like that, I'd be interested to hear about it as well.
>
> On Fri, 13 Mar 2015, Kevin A. McGrail wrote:
>
>> On 3/13/2015 5:41 PM, Shane Williams wrote:
>>> What are your favorite (not spamass-milter) options for plugging
>>> spamassassin into a milter?
>>
>> Trying to start a holy-war on the list? ;-)
>>
>> +1 for MIMEDefang.
>>
>> Regards,
>> KAM
>>
>>
>
Re: Which milter do you prefer?
Posted by sh...@shanew.net.
Well, you don't have to try very hard to start a holy war around here
;-) Seriously, though, I wasn't thinking at the level of amavisd,
mimedefang, or mailscanner.
Those may come later, but the situation I'm in right this moment is
that I'm taking over a very idiosyncratic mail environment, and I need
to tune and monitor it's performance before switching over. Thus, the
least disruptive option I see is to insert a milter for spamassassin
in front of anything else, and then score / log messages without
tampering with them in anyway, so they can continue through the milter
chain as if it weren't even there (except for some slight delay).
Spamass-milter does this, but it means running the milter on the
existing system rather than just pointing sendmail to a remote
milter. I may end up there anyhow, but I thought I'd ask first.
All this, of course, after searching high and low for a milter, proxy,
or some other contraption that would allow me to "clone" a mail stream
to a totally separate server without disrupting the original stream
(like port spanning or a network tap, but for SMTP), and finding
nothing outside of alpha or beta to do that. If anyone knows of
something like that, I'd be interested to hear about it as well.
On Fri, 13 Mar 2015, Kevin A. McGrail wrote:
> On 3/13/2015 5:41 PM, Shane Williams wrote:
>> What are your favorite (not spamass-milter) options for plugging
>> spamassassin into a milter?
>
> Trying to start a holy-war on the list? ;-)
>
> +1 for MIMEDefang.
>
> Regards,
> KAM
>
>
--
Public key #7BBC68D9 at | Shane Williams
http://pgp.mit.edu/ | System Admin - UT CompSci
=----------------------------------+-------------------------------
All syllogisms contain three lines | shanew@shanew.net
Therefore this is not a syllogism | www.ischool.utexas.edu/~shanew
Re: Which milter do you prefer?
Posted by Benny Pedersen <me...@junc.eu>.
Kevin A. McGrail skrev den 2015-03-13 22:50:
> On 3/13/2015 5:41 PM, Shane Williams wrote:
>> What are your favorite (not spamass-milter) options for plugging
>> spamassassin into a milter?
>
> Trying to start a holy-war on the list? ;-)
spampd
> +1 for MIMEDefang.
you are insane ? :=)
Hide: fuglu configured as milter, then you sooner or later do not need
more then one milter
Re: Which milter do you prefer?
Posted by "Kevin A. McGrail" <KM...@PCCC.com>.
On 3/13/2015 5:41 PM, Shane Williams wrote:
> What are your favorite (not spamass-milter) options for plugging
> spamassassin into a milter?
Trying to start a holy-war on the list? ;-)
+1 for MIMEDefang.
Regards,
KAM