Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 27 replies
  • Subscribers 2 subscribers
  • Views 42799 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

Exchange Mail stuck in Spool, using smarthost

Wedgewood
Hello,

I hope someone can help me with my outgoing email.
A few days ago I started using a Sophos UTM 9.2 as new Firewall.
Reveicing emails works fine, but sending won't work.

Before using the Firewall Exchange sends email through an Smarthost (Domainfactory) - this worked always very good.

Now I configured the UTM as a smarthost for sending emails in Exchange.
So what I want to do is to send Emails from Exchange to the UTM as smarthost. From here they should be sended to the domainfactory smarthost. Bit they stay forever in spool. This is the log-entry I got:

2014-09-16 10:06:00 Remote host smtprelaypool.ispgateway.de [80.67.29.4] closed connection in response to initial connection
2014-09-16 10:06:00 ***@*** R=smarthost_route T=smarthost_smtp defer (-18): Remote host smtprelaypool.ispgateway.de [80.67.29.4] closed connection in response to initial connection

Maybe the following information is helpful:

Mails beeing in SMTP-Spool seem to get Virus-checked twice. They show the both the footer for incoming and for outgoing scan.

I've checked the settings for the external smarthost a lot of times. It is correct.

As a Workaround I tried to use the old smarthost in Exchange, sending mail direct from exchange to the external smarthost. This doesn't seem to work as well. The UTM blocks traffic on port 465 regardless of my Firewall Settings.

Any help is appreciated, I'm getting crazy because I can't send any mail...

My configuration for SMTP:
Global: simple
Domains: all accepted
Hostlist: Mailserver (Exchange)
Verify recipients: with callout
Antivirus: Default
Advanced anti-spam Features: Disabled for testing
Data Protection: Default
Exceptions: None
Upstream Hosts/Network: External MX
Authenticated relay: allow
Host-based relay: Mailserver (Exchange)
Advanced: Use a smarthost (with authentication)


This thread was automatically locked due to age.
Parents
  • 0
    My outgoing mail stopped working a few days ago too on my home Sophos UTM. Connection to Verizons outgoing.verizon.net 567 suddenly stopped working after several years with the same configuration. Changed smart host setting to smtp.verizon.net 465 and the same closed connection messages from Verizon appear in the smtp proxy log.
Reply
  • 0
    My outgoing mail stopped working a few days ago too on my home Sophos UTM. Connection to Verizons outgoing.verizon.net 567 suddenly stopped working after several years with the same configuration. Changed smart host setting to smtp.verizon.net 465 and the same closed connection messages from Verizon appear in the smtp proxy log.
Children
  • 0 in reply to darrelld
    My outgoing mail stopped working a few days ago too on my home Sophos UTM. Connection to Verizons outgoing.verizon.net 567 suddenly stopped working after several years with the same configuration. Changed smart host setting to smtp.verizon.net 465 and the same closed connection messages from Verizon appear in the smtp proxy log.


    So I read when switching over to verizon that the outgoing.verizon.net was being depreciated, and the new address was smtp.verizon.net, however they were using port 465 like you mentioned vs port 25 like I'm using.  I believe SSL is required between UTM and verizon to use port 465, and from what I remember, that isn't supported by the UTM.  Please correct me if I'm wrong here - I'd like to switch over to the new settings if possible.

    I am using the following settings (and have been until this broke a couple days ago):

    outgoing.verizon.net port 25

    After testing MTU settings, here is what I found.  With the standard 1500 packet size on the external interface, and pinging the outgoing.verizon.net server, I could only get a 1448 byte packet through.  What's strange, is I didn't get the frag needed message until I increased the packet size up to 1473 bytes.  Between 1449 and 1472 bytes, I just received no packets back.  

    This seems very unusual to me.
Unfiltered HTML