This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Relaying authentication Qs

My last post was pretty incomprehensible, so I regrouped my thoughts!

We've got a 2nd email domain that's been added behind our Astaro.  Our original environment is all local-subnets only for sending out mail, the new email domain is all external, users are all over the country with a combination of residential and business connections.

Further complicating the issue is that there is no central authentication method for these users - no AD or anything else.  So, as of right now I've had to bypass the SMTP proxy (using DNAT) for this email domain, which is not ideal.  

What I'm trying to figure out is what the simplest way to enable these users to relay.  I'd prefer to avoid having them authenticate through the Astaro, as the SMTP server already has a comprehensive relay policy in place.  I don't see any way to let only specific domains have lax relaying policies.

Any suggestions on what to pursue?  I know it's a big no-no, but I was considering setting the allowed relay to "all" - BUT only if the individual servers relaying restrictions remained in place.   Obviously that's not something I want to test in a production environment.


This thread was automatically locked due to age.
Parents
  • You're right... the general sequence for the Astaro is "DNATs first, then Proxies, then manual routes and packet filter rules, then SNATs."

    So, if the clients are doing 25/110, you will need a DNAT for the client connections that doesn't interfere with the proxy.  The two possibilities are an additional address on the External interface or using an alternate port, like 587, instead of 25.  Of course, transparent should not be used with this.

    Cheers - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
Reply
  • You're right... the general sequence for the Astaro is "DNATs first, then Proxies, then manual routes and packet filter rules, then SNATs."

    So, if the clients are doing 25/110, you will need a DNAT for the client connections that doesn't interfere with the proxy.  The two possibilities are an additional address on the External interface or using an alternate port, like 587, instead of 25.  Of course, transparent should not be used with this.

    Cheers - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
Children
  • You're right... the general sequence for the Astaro is "DNATs first, then Proxies, then manual routes and packet filter rules, then SNATs."

    So, if the clients are doing 25/110, you will need a DNAT for the client connections that doesn't interfere with the proxy.  The two possibilities are an additional address on the External interface or using an alternate port, like 587, instead of 25.  Of course, transparent should not be used with this.

    Cheers - Bob


    The issue here is that I want the SMTP Proxy to function for incoming SMTP connections.  Right now it's configured with a DNAT so it skips the proxy.  This means the Astaro is not doing antivirus/spam scanning on anybody outside the LAN sending email into the domain.   

    If I disable the DNAT and actually have the Astaro intercept incoming SMTP connections, it then uses the relay settings configured in the proxy - which do not allow outside users to relay, which they HAVE to do to send out emails through the domain.

    What I'm trying to do is figure out how to allow the SMTP proxy to scan incoming connections while still allowing outside clients to relay. 

    If I add the SMTP server to "host-based relay", it does not work.  I know you said not to use transparent mode to test it, but what exactly about transparent mode would make any difference?  I thought it just automatically intercepted port 25 traffic, and everything else about the proxy remained the same.