Getting SMTP relay error on internal SMTP machine

Normally it should be possible to send to internal mail servers and external mailserver using the smtp proxy and user authentication. I don't know if I get you right:

Your setup:

Code:

---

externalMailserver----
                      |
                     www---ASL---internalMailserver
                      |
MailClient------------
(sends all mails to ASL using authentication)

---

Is that right?

Xeno

Hi,

the authentication process dosent differ between internal and external net. So if you didnt configure Authentication on you internal mail server, it cant connect to the ASL to send the mail. 

Normaly you can specify the smarthost option with username and pw on most mail-server systems. Also a few older systems dont support user authentication for outgoing mails. 

Chris

[ QUOTE ]
I am trying to allow some external users the ability to use our SMTP machine in order to send emails out that appear like they come from us - as they are supposed to.

[/ QUOTE ]
Doing so exposes your SMTP proxy to the outside. Even if you have been carefull to only allow people with valid IDs and passwords to use it, it might make your ISP think you have an open mail relay.

An alternate approach is to not open the SMTP proxy to external access, and instead telling the remote users to open a roadwarrier VPN tunnel first. Then they can send their mail to the SMTP proxy inside the tunnel. Since the mail no longer arrives at the proxy from outside,  your current problem should disappear.

I set it up according to astaro's own docs, for allowing smtp relay using local user accounts with smtp access. I have everything working EXCEPT *some* of the client PC's get an expected "this cert chain terminates in a root that is not trusted" since I'm using the default cert that is magically installed by default. This makes sense. Unfortunately other clients just plain barf on TLS saying it doesn't work. What cert is TLS using? How can I extract this cert so I can send it to the clients for manual insertion into their own email trusted cert chain?

My setup is like this:

+-- TrustedEmailClient
 |
 + -- Internet -- ASL -- InternalEmailServer
 |
 + -- every other email server in the world

I'm allowing trusted email client to logon using an ASL local account that allows SMTP relay into the internal email server. ASL is currently spam/virii checking everything before relaying it on. The problem is I want to leave TLS on so the trusted email client SMTP connection into ASL is encrypted as expected, every other SMTP server can connect in to deliver email as expected, and the trusted email client can bounce the SMTP request into InternalEmailServer and it gets back out again having been sent just as if the trustedEmailClient was internal to our own network.

As I mentioned before, I have this mostly working except for some clients simply complain about the TLS connection giving an untrusted root cert error, while others just simply bail not allowing me to continue on at all.

How do I get the trusted email clients to stop complaining about the validity of the default magical TLS cert?

You can turn TLS off and use plain text username and password.  Works for us.

You can also download the CERT and install it on your clients.
If you search the forums you should be able to find where it is kept.

[ QUOTE ]
What cert is TLS using?

[/ QUOTE ]As far as I know, it uses the same ASL internally generated certificate used by the HTTPS webadmin. It should get downloaded into the mail clients automatically the first time they try to send TLS encrypted mail.

If you go with my initial suggestion, of having remote users open a roadwarrior VPN before accessing the SMTP service, then the need for using TLS encryption disappears.

I turned off TLS and the firewall became a spam zombie in two days.

It looks like the VPN solution is the only one that is going to work.

Did you use plain text auth??

I'm not using TLS and system works fine. (No spam relaying)