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.
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.pixelpointstudios.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.
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).
or
2) 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. :)
Related info:
http://www.postfix.org/postconf.5.html#smtpd_sasl_authenticated_header
http://wiki.apache.org/spamassassin/DynablockIssues
Daryl
