Re: Handling very large messages (was Re: Which milter do you prefer?)
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?)
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 signature.asc Description: OpenPGP digital signature
Re: Handling very large messages (was Re: Which milter do you prefer?)
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: Which milter do you prefer?
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: Handling very large messages (was Re: Which milter do you prefer?)
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 signature.asc Description: OpenPGP digital signature
Re: Handling very large messages (was Re: Which milter do you prefer?)
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, uh...@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?)
On Mon, 16 Mar 2015 10:51:59 -0400
"Bill Cole" 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?)
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?)
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: URI_DOTDOT_LOW_CNTRST false positives?
On 03/16/2015 11:43 AM, Per Jessen wrote: Axb wrote: On 03/16/2015 11:28 AM, Per Jessen wrote: Axb wrote: On 03/16/2015 11:05 AM, Axb wrote: On 03/16/2015 10:54 AM, Per Jessen wrote: I've recently upgraded to SA 3.4.0 - I'm seeing URI_DOTDOT_LOW_CNTRST scoring on many legitimate mails. E.g. from linkedin and distrelec. For instance: http://files.jessen.ch/Tektronix-4-Kanal-Oszilloskop-deutlich-reduziert-TDS-2024C.eml When the above was processed I noticed this in the log: spamd[865]: dns: new_dns_packet (domain=chde..distrelec.com. type=A class=IN) failed: a domain name contains a null label As far as I can tell, the email above contains no such uri. I grep'ed a bit and found some more: http://files.jessen.ch/more-dotdot.txt I'm pretty certain 99% of those are false positives. Probably a hiccup on my installation, I was just wondering if anyone else is seeing this? Which .cf file is this in? Can't find it in SA trunk's .cf files. ok.. sorry - found it but atm it seems it isn't being autopromoted have you run a recent sa-update ? I think the ruleset is from the tarball from the apache page. Hmm, it would appear to be quite old ?? http://mirror.reverse.net/pub/apache//spamassassin/source/Mail-SpamAssassin-rules-3.4.0.r1565117.tgz Dated 20Feb2014. Is there a recent tarball somewhere? iirc, that is the 3.4 release rules version sa-update would provide the latest ruleset Yup, got it. Might not be a bad idea if the apache downloads page had a link to the most recent rule-set too. (or even instead of the original). for review before applying I often use sa-update -D --updatedir /tmp/sa-work This gets the latest tarball and unpacks the rules Should be trivial to hack sa-update so it just gets the latest archive. Putting on the downloads page means it has to be watched that all mirrors are in sync... the update mirrors are easier to control. Anyway, problem solved, thanks. My pleasure... Axb
Re: URI_DOTDOT_LOW_CNTRST false positives?
On 03/16/2015 10:54 AM, Per Jessen wrote: I've recently upgraded to SA 3.4.0 - I'm seeing URI_DOTDOT_LOW_CNTRST scoring on many legitimate mails. E.g. from linkedin and distrelec. For instance: http://files.jessen.ch/Tektronix-4-Kanal-Oszilloskop-deutlich-reduziert-TDS-2024C.eml When the above was processed I noticed this in the log: spamd[865]: dns: new_dns_packet (domain=chde..distrelec.com. type=A class=IN) failed: a domain name contains a null label As far as I can tell, the email above contains no such uri. I grep'ed a bit and found some more: http://files.jessen.ch/more-dotdot.txt I'm pretty certain 99% of those are false positives. Probably a hiccup on my installation, I was just wondering if anyone else is seeing this? your more-dotdot.txt log shows what could be a bug somewhere. Pls open a bug & attach that log and the distrelec news eml with all relevant detail if you have more verified sample msgs which don't include a .. in the URL yet log .., pls attach a few for dev team to work with. Thanks Axb
Re: URI_DOTDOT_LOW_CNTRST false positives?
On March 16, 2015 10:55:22 AM Per Jessen wrote: spamd[865]: dns: new_dns_packet (domain=chde..distrelec.com. type=A class=IN) failed: a domain name contains a null label uri with ..
Re: URI_DOTDOT_LOW_CNTRST false positives?
Axb wrote: > On 03/16/2015 11:28 AM, Per Jessen wrote: >> Axb wrote: >> >>> On 03/16/2015 11:05 AM, Axb wrote: On 03/16/2015 10:54 AM, Per Jessen wrote: > I've recently upgraded to SA 3.4.0 - I'm seeing > URI_DOTDOT_LOW_CNTRST scoring on many legitimate mails. E.g. from > linkedin and distrelec. > > For instance: > >> http://files.jessen.ch/Tektronix-4-Kanal-Oszilloskop-deutlich-reduziert-TDS-2024C.eml > > > When the above was processed I noticed this in the log: > > spamd[865]: dns: new_dns_packet (domain=chde..distrelec.com. > type=A class=IN) failed: a domain name contains a null label > > As far as I can tell, the email above contains no such uri. > > I grep'ed a bit and found some more: > > http://files.jessen.ch/more-dotdot.txt > > I'm pretty certain 99% of those are false positives. Probably a > hiccup on my installation, I was just wondering if anyone else is > seeing this? Which .cf file is this in? Can't find it in SA trunk's .cf files. >>> >>> ok.. sorry - found it but atm it seems it isn't being autopromoted >>> >>> >>> have you run a recent sa-update ? >> >> I think the ruleset is from the tarball from the apache page. Hmm, >> it would appear to be quite old ?? >> >> http://mirror.reverse.net/pub/apache//spamassassin/source/Mail-SpamAssassin-rules-3.4.0.r1565117.tgz >> >> Dated 20Feb2014. >> >> Is there a recent tarball somewhere? > > iirc, that is the 3.4 release rules version > > sa-update would provide the latest ruleset Yup, got it. Might not be a bad idea if the apache downloads page had a link to the most recent rule-set too. (or even instead of the original). Anyway, problem solved, thanks. -- Per Jessen, Zürich (8.4°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland.
Re: URI_DOTDOT_LOW_CNTRST false positives?
On 03/16/2015 11:28 AM, Per Jessen wrote: Axb wrote: On 03/16/2015 11:05 AM, Axb wrote: On 03/16/2015 10:54 AM, Per Jessen wrote: I've recently upgraded to SA 3.4.0 - I'm seeing URI_DOTDOT_LOW_CNTRST scoring on many legitimate mails. E.g. from linkedin and distrelec. For instance: http://files.jessen.ch/Tektronix-4-Kanal-Oszilloskop-deutlich-reduziert-TDS-2024C.eml When the above was processed I noticed this in the log: spamd[865]: dns: new_dns_packet (domain=chde..distrelec.com. type=A class=IN) failed: a domain name contains a null label As far as I can tell, the email above contains no such uri. I grep'ed a bit and found some more: http://files.jessen.ch/more-dotdot.txt I'm pretty certain 99% of those are false positives. Probably a hiccup on my installation, I was just wondering if anyone else is seeing this? Which .cf file is this in? Can't find it in SA trunk's .cf files. ok.. sorry - found it but atm it seems it isn't being autopromoted have you run a recent sa-update ? I think the ruleset is from the tarball from the apache page. Hmm, it would appear to be quite old ?? http://mirror.reverse.net/pub/apache//spamassassin/source/Mail-SpamAssassin-rules-3.4.0.r1565117.tgz Dated 20Feb2014. Is there a recent tarball somewhere? iirc, that is the 3.4 release rules version sa-update would provide the latest ruleset
Re: URI_DOTDOT_LOW_CNTRST false positives?
Axb wrote: > On 03/16/2015 11:05 AM, Axb wrote: >> On 03/16/2015 10:54 AM, Per Jessen wrote: >>> I've recently upgraded to SA 3.4.0 - I'm seeing >>> URI_DOTDOT_LOW_CNTRST scoring on many legitimate mails. E.g. from >>> linkedin and distrelec. >>> >>> For instance: >>> http://files.jessen.ch/Tektronix-4-Kanal-Oszilloskop-deutlich-reduziert-TDS-2024C.eml >>> >>> >>> When the above was processed I noticed this in the log: >>> >>> spamd[865]: dns: new_dns_packet (domain=chde..distrelec.com. type=A >>> class=IN) failed: a domain name contains a null label >>> >>> As far as I can tell, the email above contains no such uri. >>> >>> I grep'ed a bit and found some more: >>> >>> http://files.jessen.ch/more-dotdot.txt >>> >>> I'm pretty certain 99% of those are false positives. Probably a >>> hiccup on my installation, I was just wondering if anyone else is >>> seeing this? >> >> Which .cf file is this in? >> Can't find it in SA trunk's .cf files. >> > > ok.. sorry - found it but atm it seems it isn't being autopromoted > > > have you run a recent sa-update ? I think the ruleset is from the tarball from the apache page. Hmm, it would appear to be quite old ?? http://mirror.reverse.net/pub/apache//spamassassin/source/Mail-SpamAssassin-rules-3.4.0.r1565117.tgz Dated 20Feb2014. Is there a recent tarball somewhere? -- Per Jessen, Zürich (8.2°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland.
Re: URI_DOTDOT_LOW_CNTRST false positives?
On 03/16/2015 11:05 AM, Axb wrote: On 03/16/2015 10:54 AM, Per Jessen wrote: I've recently upgraded to SA 3.4.0 - I'm seeing URI_DOTDOT_LOW_CNTRST scoring on many legitimate mails. E.g. from linkedin and distrelec. For instance: http://files.jessen.ch/Tektronix-4-Kanal-Oszilloskop-deutlich-reduziert-TDS-2024C.eml When the above was processed I noticed this in the log: spamd[865]: dns: new_dns_packet (domain=chde..distrelec.com. type=A class=IN) failed: a domain name contains a null label As far as I can tell, the email above contains no such uri. I grep'ed a bit and found some more: http://files.jessen.ch/more-dotdot.txt I'm pretty certain 99% of those are false positives. Probably a hiccup on my installation, I was just wondering if anyone else is seeing this? Which .cf file is this in? Can't find it in SA trunk's .cf files. ok.. sorry - found it but atm it seems it isn't being autopromoted have you run a recent sa-update ? John Hardin, your sandbox limit score of 2.5 seems sorta high..
Re: URI_DOTDOT_LOW_CNTRST false positives?
On 03/16/2015 10:54 AM, Per Jessen wrote: I've recently upgraded to SA 3.4.0 - I'm seeing URI_DOTDOT_LOW_CNTRST scoring on many legitimate mails. E.g. from linkedin and distrelec. For instance: http://files.jessen.ch/Tektronix-4-Kanal-Oszilloskop-deutlich-reduziert-TDS-2024C.eml When the above was processed I noticed this in the log: spamd[865]: dns: new_dns_packet (domain=chde..distrelec.com. type=A class=IN) failed: a domain name contains a null label As far as I can tell, the email above contains no such uri. I grep'ed a bit and found some more: http://files.jessen.ch/more-dotdot.txt I'm pretty certain 99% of those are false positives. Probably a hiccup on my installation, I was just wondering if anyone else is seeing this? Which .cf file is this in? Can't find it in SA trunk's .cf files.
URI_DOTDOT_LOW_CNTRST false positives?
I've recently upgraded to SA 3.4.0 - I'm seeing URI_DOTDOT_LOW_CNTRST scoring on many legitimate mails. E.g. from linkedin and distrelec. For instance: http://files.jessen.ch/Tektronix-4-Kanal-Oszilloskop-deutlich-reduziert-TDS-2024C.eml When the above was processed I noticed this in the log: spamd[865]: dns: new_dns_packet (domain=chde..distrelec.com. type=A class=IN) failed: a domain name contains a null label As far as I can tell, the email above contains no such uri. I grep'ed a bit and found some more: http://files.jessen.ch/more-dotdot.txt I'm pretty certain 99% of those are false positives. Probably a hiccup on my installation, I was just wondering if anyone else is seeing this? -- Per Jessen, Zürich (6.3°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland.
Re: Handling very large messages (was Re: Which milter do you prefer?)
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. SKIPStop 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?)
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 signature.asc Description: OpenPGP digital signature
Re: Which milter do you prefer?
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)
