Q about mail proxy servers and setups

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?

-- 
Michael Scheidell, CTO
Office: 561-999-5000 x 1259
Direct: 561-939-7259
Join SECNAP at SecureWorld Detroit 9-10
http://www.secnap.com/ev
ents for free and discounted seminar tickets  
____________________________________________________________
_____________
This email has been scanned and certified safe by
SpammerTrap(tm). 
For Information please see http://www.spammertrap.com

____________________________________________________________
_____________

------------------------------------------------------------
-------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
AMaViS-user mailing list
AMaViS-userlists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amavis-user

AMaViS-FAQ:http://www.amav
is.org/amavis-faq.php3
AMaViS-HowTos:http://www.amavis.org/ho
wto/

On Sun, Sep 23, 2007 at 01:50:43PM -0400, Michael Scheidell
wrote:

[Please post to one list only. Since I'm not subscribed to
spamasassin-users, I removed that list]

> 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.

What do you mean with "proxy"? A MTA running
spamassassin, amavis,
whatever can be a proxy, of course.

> #1, SPF.  SPF helo, SENDERID
>   The proxy will be adding a received header, and
announcing 'HELO/EHLO'
> using its own name, not the senders.

You can never rely on EHLO/HELO. Even if it is not faked or
misconfigured, it need not to be the original senders host.

> #2, many blacklists that depend on the last received
header (the proxy
> will normally put on in)

If your DMZ MTA gots blacklisted, you have other problems.

> 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.

That is why you want to have filtering on your DMZ MTA, not
on the
internal MTA.

> 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'.

See above.

> Any solutions other then take the proxy server out and
replace it with
> the SpamAssassin/MTA combo?

I'm really unsure what a "proxy" is for you.

Rainer

------------------------------------------------------------
-------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
AMaViS-user mailing list
AMaViS-userlists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amavis-user

AMaViS-FAQ:http://www.amav
is.org/amavis-faq.php3
AMaViS-HowTos:http://www.amavis.org/ho
wto/

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

------------------------------------------------------------
-------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
AMaViS-user mailing list
AMaViS-userlists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amavis-user

AMaViS-FAQ:http://www.amav
is.org/amavis-faq.php3
AMaViS-HowTos:http://www.amavis.org/ho
wto/

On Sun, Sep 23, 2007 at 01:50:43PM -0400, 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.
...
> #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?

  I think most of your commenters missed this last
paragraph.  (I
sympathise with the difficulty of getting *any* change in
place in the
large corporate model, let alone one which involves other
departments. 
I spent half last year working as a contract software
developer inside
a major multinational, and while I could have offered better
solutions
for several areas than their IT department, it would have
been useless
for me to volunteer that.)

  #1, semi-correct, but meh.  I'm unconvinced that SPF would
help you
very much except as it provides for some useful
whitelisting
mechanisms.  The MTA is the wrong place to check it, though;
see next
paragraph.

  Your point #2 *can* be worked around at the SpamAssassin
level, by
configuring the proxy (or potentially multiple parallely
proxy servers)
as part of SpamAssassin's "Trusted networks"
configuration.  Note that
trusted and *internal* are not the same; trusted simply
means that the
MTA is not subverted and that you can rely on it to tell you
where mail
really came in from.  It would require a bit of hacking to
do something
similar in amavisd, I think, so you would have to rely on
SA's own
blacklisting/whitelisting features.  In this context, if you
get the SA
config right, you *can* use SPF by having SA evaluate it,
looking back
through the received headers to where it really came in
from.  I did
something similar to scan back through received headers in
some custom
software I wrote (sadly, not available to open source as I
wished to.)

  Graylisting and throttling are pointless once the mail is
within
the corporate network, correct.  With regard to p0f, again
you've
covered it - part of the information might be there but even
if you can
get the proxy to forward you the IP via XFORWARD, it won't
have the
fingerprint info.  That too needs to come from the point of
contact.

  As to your next-to-last point, it would definitely be
*incorrect* to
put the proxy in MY_NETS.  It should be configured in
amavisd just as
you would configure an MX server which mail comes through. 
That would
be a distinct policy from either MY_NETS or the typical
incoming mail
policy, IMHO.

 If the powers-that-be are unable to consider open source as
an
alternative, perhaps they would consider some of the
commercial
products which can perform similarly to amavisd with enough
tuning. 
The problem is that a lot of the commercial products are,
not to put a
fine point on it, crap.  When the IT departments are fixated
on
Microsoft, and trying to run anything on top of Exchange,
that's a
killer.  (Not that Exchange belongs in a DMZ in any case.) I
hear Lyris
Mailshield can be made to do some pretty impressive
filtering, if you
tweak it enough.

  In summary, if a corporate SMTP proxy filter is inadequate
to shield
the corporation from spam, unfortunately you are left with a
relatively
limited subset of today's antispam features which you can
actually use
on the inside.  In the end, the corporation has to live with
(or die
with) the choice of filtering technology it has made.

  -- Clifton

-- 
    Clifton Royston  --  cliftonriandicomputing.com /
cliftonrlava.net
       President  - I and I Computing * http://www.iandicomput
ing.com/
 Custom programming, network design, systems and network
consulting services

------------------------------------------------------------
-------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
AMaViS-user mailing list
AMaViS-userlists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amavis-user

AMaViS-FAQ:http://www.amav
is.org/amavis-faq.php3
AMaViS-HowTos:http://www.amavis.org/ho
wto/