Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 9 replies
  • Subscribers 1 subscriber
  • Views 3684 views
  • Users 0 members are here
Options
Suggested
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

Getting SMTP relay error on internal SMTP machine

predatorsw
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. If I set up outgoing SMTP authentication then they can logon to the SMTP proxy and into my internal SMTP server fine BUT all mail going to external SMTP servers gets authentication failures. So I want SMTP authentication when the SMTP proxy is trying to relay email through my SMTP server, but NO authentication as the email server is sending out to the real world.

Does this make sense?

The alternative is to turn off SMTP authentication on the SMTP machine and I'm a bit leary of doing that.


This thread was automatically locked due to age.
Parents
  • 0
    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
  • 0 in reply to Xeno
    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?
Reply
  • 0 in reply to Xeno
    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?
Children
No Data
Cookie Information Banner