[clamav-users] ign2 whitelist don't work

[Reindl Harald]

Am 19.07.2016 um 16:02 schrieb Charles Swiger:
> Perhaps English isn't your native language?

no, it isn't

first: i know that SPF is not relevant for clamav, but since it's a 
clean way to verify the source of a message and clamav can't do this 
such spoofing rules in clamav which can't be disabled without disable 
other things too is bad

second: i know about scoring - as said i have more than one clamd and 
what i had to do now is move safebrowsing rules to the other instance 
because they whould have disabled too by "PhishingScanURLs no"

yes, i know that the milter is not flexible and *hence* there are 
different clamd instances with different configs and different 
signatures - *but* the last ressort instance for clamav-milter is 
terrible unflexible to configure because the weakness of ign2 which is 
waht this topic is about and hence i would nearly need 3 instances to 
get the granualry i need - but that's not really doable because 
currently the two running instances eare eating around 800 MB RAM

> I spoke precisely; I did not say that epsl1.com was the sending domain.  Your logs demonstrate that it, or more precisely mta106b.pmx1.epsl1.com was the MTA sending the message to your mailserver and that mail.paypal.at was the SMTP "Mail from" domain.

and so what business has "epsl1.com" in context of SPF for @mail.paypal.at?

>>> which domain not only doesn't appear in the SPF records for paypal.com / paypal.at, but also doesn't appear to have any published MX records at all (per "dig -t mx epsl1.com.")...?
>>
>> sorry but you don't understand SPF really good and since when have MX records something to do with outbound mail
>>
>> mail.paypal.at.         3600    IN      TXT     "v=spf1 ip4:142.54.244.96/27 ip4:142.54.244.128/29 -all"
>>
>> 142.54.244.106 is the sending IP
>
> Two points:
>
> 1) I got different SPF results here, although hitting a third-party website to lookup the SPF records for mail.paypal.at does give the result you've shown.  (I'm travelling and using someone else's network at the moment, so it's possible that they/their ISP is swizzling DNS lookups.)

or you did "dig TXT paypal.at" which is not the same as "dig TXT 
mail.paypal.at"

anyways - "dig NS paypal.at"
paypal.at.              300     IN      NS      ns2.p57.dynect.net.
paypal.at.              300     IN      NS      ns1.p57.dynect.net.
paypal.at.              300     IN      NS      ns3.p57.dynect.net.
paypal.at.              300     IN      NS      ns4.p57.dynect.net.

dig TXT mail.paypal.at @ns2.p57.dynect.net
mail.paypal.at.         3600    IN      TXT     "v=spf1 
ip4:142.54.244.96/27 ip4:142.54.244.128/29 -all"

> 2) In the absence of MX records stating otherwise, I expect that any mailserver which sends outbound email should be willing to accept inbound mail for the same domains it terminates or relays email on behalf of.

that is not how email works

a) the sender is @mail.paypal.at and not "@epsl1.com"
b) every smarter setup these days has strictly
    seperated outbound and inbound servers

what you expect is completly pointless - as example you have no business 
to deliver mail to our outbound server unless you are a customer with a 
valid username and password since inbound mail is expected at the MX 
(spamfirewall) and not at the submission server

why?

because it's much easier to define MTA policies for spamfiltering when 
you need not to mix with mail clients and when you do outbound 
spamfiltering you need completly different rules (no RBL looksups, no 
PTR checks, different scorings and first of all no postscreen in front 
which a MUA can't handle)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <https://lists.clamav.net/pipermail/clamav-users/attachments/20160719/5fd09c42/attachment.sig>