Am 19.07.2016 um 16:02 schrieb Charles Swiger:
Perhaps English isn't your native language?
no, it isn'tfirst: 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 IPTwo 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.netmail.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 serverswhat 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)
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Help us build a comprehensive ClamAV guide: https://github.com/vrtadmin/clamav-faq http://www.clamav.net/contact.html#ml
