On 10-Jul-06, at 7:39 PM, Daryl C. W. O'Shea wrote:
Gino Cerullo wrote:On 10-Jul-06, at 5:49 PM, Daryl C. W. O'Shea wrote:If the MSA in question is *ONLY* an MSA, you're easiest quickest fix is to just not trust it (or mark it as trusted but not internal).If I'm understanding you correctly, I'm fairly new to this, then no, the MSA (Mail Submission Agent) is also the MTA (Mail Transfer Agent.) All mail for the domains in question are received and delivered by this one server.trusted_networks lists my public and private IP addresses (WAN & LAN) internal_networks lists only private IP addresses (LAN)These are incorrect for your setup. Trusted and internal networks should both list YOUR public and private IP addresses. IP addresses of other people could go in trusted networks only, but don't even bother with that.The only 'one' of your addresses that wouldn't go in internal networks would be your MSA if it was only an MSA, but yours isn't as you've said it's also working as an MX.I think that's how those are suppose to work. I haven't bothered to try and list the IPs where outside users may connect from since that can be anywhere.So... fixing the above will resolve your SPF (and other) issues for LAN users. Add all the IP space you control to trusted networks (including your internal RFC 1938 ranges). Don't even bother with setting internal networks. In your case they'll be the same as your trusted networks, so SA will just copy them for you if you leave internal networks unset.
Thanks for the clarification. I'll make the changes.
That still leaves a problem with your roaming users not being trusted. Postfix makes this oh so fun.If SA is running on that host, or it's also doing another mail function, MX or intermediate relay, etc., then describe your mail topology and we'll help you out.Okay, this one server is running Postfix, Amavisd-new, Spamassassin, ClamAV, pretty standard stuff. This server does not relay to any other servers for mail delivery and is not a relay for any servers. Both incoming and outgoing mail is handled by Postfix which hands it off to Amavisd-new which calls Spamassassin and ClamAV to scan the message. Clean email is handed back to Postfix to complete delivery. Bad email is quarantined by Amavis- new. At least that's my understanding of how it works. Generally, because of SPF, all users submit directly to this server and all outgoing email for the domains handled by this server are delivered directly by this server, no relays involved. Fairly simple stuff and it all works as expected except for SA.This is what I'm seeing if it helps.0.9 SPF_FAIL SPF: sender does not match SPF record (fail) [SPF failed: Please see http://www.openspf.org/why.html? sender=dmaguire% 40maguiremarketing.com&ip=24.42.90.104&receiver=server.pixelpointstud ios.lan] maguiremarketing.com is hosted by the server in question. 24.42.90.104 is the IP address that he is connecting from. In this case it's the IP assigned dynamically to his router by his cable company (ISP). Like I said the Postfix policy daemon that checks SPF correctly ignores this IP address as it represents the MUA (Mail User Agent.) I guess I'm expecting SA to know that as well but I guess it doesn't.You can't expect SA to do something based on information that Postfix has and SA doesn't (because Postfix doesn't give it up, at least not easily), that is, SA doesn't know the user is an authenticated user while Postfix does.
This is what I thought. Thanks for confirming this as well.
You have two options: 1) Quoting mouss... mouss wrote: > martin f krafft a écrit : >> Well, sure, this makes sense, but how can I support this standard>> use-case? Postfix adding a SASL-header that causes Spamassassin then >> to ignore the message isn't the solution as spammers would simply do>> that sooner or later. Short of whitelisting people, what should >> I do? >> > > how do you integrate SA with postfix? >> If using content_filter, then you could skip SA for authenticated users.> for instance: > > content_filter= > #or this to still check for viruses: > #content_filter=scan:[clamsmtp.domain.example]:10020 > smtpd_recipient_restrictions = > ... > permit_sasl_authenticated > permit_mynetworks > reject_unauth_destination > check_client_access pcre:/etc/postfix/default_filter.pcre > ... > > == default_filter.pcre: > /./ FILTER scan:[amavisd.domain.example]:10024 > > ('scan' is the name of the transport as defined in master.cf).
I see but is the trade-off here that if SA skips authenticated users and they are compromised then they can become spam sources that wouldn't be caught locally or does it only skip SPF and still do all other scans?
or2) Upgrade to Postfix 2.3, if necessary, set "smtpd_sasl_authenticated_header yes" in your Postfix config and then offer to buy me lunch next time I'm in the city to persuade me to make a patch to support this. :)
Are you a contributor to SA's development?I guess the same compromise will exist in this scenario? Would it be difficult to get SA to see that the user is authenticated and just skip SPF but still do everything else?
I see from the header in the message you sent that you have deployed DKIM. I'm hoping to do that as well but not for a while yet. Do similar problems arise with DKIM and SA as we've discussed here with SPF?
No problem. I eat lunch...usually...if I remember to. It's amazing how fast the day goes by when you're busy.
Related info: http://www.postfix.org/postconf.5.html#smtpd_sasl_authenticated_header http://wiki.apache.org/spamassassin/DynablockIssues Daryl
Thanks for all your help and suggestions. -- Gino Cerullo Pixel Point Studios 21 Chesham Drive Toronto, ON M3M 1W6 T: 416-247-7740 F: 416-247-7503
smime.p7s
Description: S/MIME cryptographic signature
