Every problem you've named here is solved by putting Amavis/SA on the
proxy instead of the internal system.
If the proxy doesn't do the spam-checking, and the internal system does
I can name a dozen other problems that will occur, the most important of
which will be backscatter. 2-step relay where the internal system
doesn't trust the external system is a backscatter system, and will get
blacklisted fairly quickly.
Michael Scheidell wrote:
Sometimes a large company will have a proxy server set up in the DMZ and
then send it to their internal mail server.
I understand that ideally, the proxy server would be replaces with a
SpamAssassin/MTA setup.
However, sometimes, client, security and company policy needs outweigh
logic.
I can think of several things this might break, depending on if you
count that proxy server as an internal/trusted server.
#1, SPF. SPF helo, SENDERID
The proxy will be adding a received header, and announcing 'HELO/EHLO'
using its own name, not the senders.
(please no bitching about SPF)
#2, many blacklists that depend on the last received header (the proxy
will normally put on in)
For Amavisd/others that use p0f, all we get is signature of the proxy.
Smtp ratelimiting, greyisting, even recipient verification break. You
can't drop the SMTP session when the sender sends you an email with a
bad address, the proxy has already accepted it. You can't use 4xx
errors in your policy server to do greylisting on policy blacklisting
because you are sending the 4xx error to the proxy.
On amavis, if we use MY_NETS policy, and we put the proxy ip in the
'localnets', it will spam the spam and virus contact address on every
email from the 'local network'.
If you don't put it in there, it breaks some of the things I mentioned
above.
Anything else I missed?
Any solutions other then take the proxy server out and replace it with
the SpamAssassin/MTA combo?
--
Jo Rhett
Net Consonance ... net philanthropy, open source and other randomness
