We help IT Professionals succeed at work.

SMTP connector protocol event sink error

1,292 Views
Last Modified: 2013-11-30
I am having a very odd problem with SMTP protocol sink error.  Everything I've found points to dns, but all dns looks good, dnsdiag is not throwing any errors, etc.  Here is the config:

Server uses Exchange Hosted Services for inbound and outbound email.  Also uses Exchange hosted archive service.  To complicate matters further, most users are using IMAP to get to the server, and relaying their sent mail through the server.

To lock down SMTP so it only received anonymous inbound mail from EHS servers, I did the following:

Set up default SMTP connector to NOT use anonymous authentication.  Only authenticated users can send or relay mail.  This connector is forced to IP 192.168.1.3 and has a one-to-one NAT in the firewall to a public IP.  Users connect to this public IP on port 25, authenticate, and relay email.  This is all working just fine, mail to internal Exchange users and external internet users is flowing correctly (as long as the users can actually connect to port 25 from their ISP).  I call this connector "Inbound Authenticated Email".

Second SMTP connector set up for anonymous inbound email, but connection restrictions set up to only allow email from EHS server farm.  This connector is force to 192.168.1.4 and is mapped to another public IP in the firewall.  EHS is set to send all inbound mail to this IP only.  This is working, it blocks anonymous connections from everyone but EHS, and inbound email is flowing fine.

Now, BOTH smtp connectors are set to use mail.global.frontbridge.com as a smart host.  Any email sent by anyone, external or internal, to an Internet address is relayed through EHS.  This is *almost* all working.  Most email gets through correctly, with one exception:  NDR's generated by the Exchange server are not sent back to EHS.  Small problem at this point, I'll deal with it when I fix the bigger issue, but wanted to mention it in case it was related.  I call this connector "Inbound EHS Email".

Here's where it gets even more complicated:
I also use Exchange Journaling to journal ALL email to the EHS archive.  The setup is like this: I have a mail enabled contact with the SMTP address of the archive user, and the mailbox store is set to journal to that contact.  All mail seems to be journaled to the correct address, and mail sent to the archive address seems to randomly pick an SMTP connector to send out on.  If it goes out the "Inbound Authenticated Email" connector all is well, it is delivered to the smart host.  However, if it happens to pick "Inbound EHS Email" as a route, it stops in queue with an error "The connection was dropped due to an SMTP protocol event sink".  Problem with DNS?  Not that I can find.  Here's the interesting part: If I stop and restart "inbound EHS email" SMTP connector, just once, the email in queue disappears.   It looks like it all goes out the "Inbound Authenticated Email" connector.  Then, mail starts building up in the "Inbound EHS email" queue again, all destined for the archive.

I mentioned the NDR issue above because there is also this symptom:  All NDR's send through "Inbound EHS email" connector also generate the protocol sink error.  The only thing in the queue for "inbound EHS email" connector are NDR's and journaled emails.  OTHER EMAIL IS SENT TO THE SMARTHOST!  Also, everything is sent to the smart host on the other connector, and there are never any NDR's in queue on that connector.

Since I have a smart host on both connectors, the expected behavior is I will never have anything in queue at all.

Of course, EHS/Microsoft has wiped their hands of this problem entirely, due to complexity.  I thought I'd post here before I paid for an M$ "Support" call.

Here are SMTP log entries for both types, with names changed to protect the innocent:

Archive email on the connector that doesn't make it (note the FROM address is blank, I did not remove it, but I think the envelope in journaling doesn't set a from address).

213.199.154.22 - OutboundConnectionResponse [05/Aug/2008:09:20:38 -0800] "- -?220 mail93-dub.bigfish.com ESMTP Postfix EGGS and Butter SMTP" 0 56
213.199.154.22 - OutboundConnectionCommand [05/Aug/2008:09:20:38 -0800] "EHLO -?mail.mydomain.com SMTP" 0 4
213.199.154.22 - OutboundConnectionResponse [05/Aug/2008:09:20:38 -0800] "- -?250-mail93-dub.bigfish.com SMTP" 0 26
213.199.154.22 - OutboundConnectionCommand [05/Aug/2008:09:20:38 -0800] "MAIL -?FROM:<> SIZE=50088 SMTP" 0 4

Here is a log snippet from the other connector, that does make it:

216.32.180.22 - OutboundConnectionResponse [05/Aug/2008:09:26:43 -0800] "- -?220 mail32-va3.bigfish.com ESMTP Postfix EGGS and Butter SMTP" 0 56
216.32.180.22 - OutboundConnectionCommand [05/Aug/2008:09:26:43 -0800] "EHLO -?outbound.mydomain.com SMTP" 0 4
216.32.180.22 - OutboundConnectionResponse [05/Aug/2008:09:26:43 -0800] "- -?250-mail32-va3.bigfish.com SMTP" 0 26
216.32.180.22 - OutboundConnectionCommand [05/Aug/2008:09:26:43 -0800] "MAIL -?FROM:<> SIZE=7255 SMTP" 0 4
216.32.180.22 - OutboundConnectionResponse [05/Aug/2008:09:26:43 -0800] "- -?250 Ok SMTP" 0 6
216.32.180.22 - OutboundConnectionCommand [05/Aug/2008:09:26:43 -0800] "RCPT -?TO:<copy.1234@archive.messaging.microsoft.com> SMTP" 0 4
216.32.180.22 - OutboundConnectionResponse [05/Aug/2008:09:26:43 -0800] "- -?250 Ok SMTP" 0 6
216.32.180.22 - OutboundConnectionCommand [05/Aug/2008:09:26:43 -0800] "DATA - SMTP" 0 4
216.32.180.22 - OutboundConnectionResponse [05/Aug/2008:09:26:44 -0800] "- -?354 End data with <CR><LF>.<CR><LF> SMTP" 0 35
216.32.180.22 - OutboundConnectionResponse [05/Aug/2008:09:26:44 -0800] "- -?250 Ok: queued as EBAB28D0066 SMTP" 0 29
216.32.180.22 - OutboundConnectionCommand [05/Aug/2008:09:26:44 -0800] "QUIT - SMTP" 0 4
216.32.180.22 - OutboundConnectionResponse [05/Aug/2008:09:26:44 -0800] "- -?221 Bye SMTP" 0 7

I've compared the settings on both connectors, and other than the settings that are different because of their purpose (i.e. connection filters on the inbound EHS, anonymous auth on the inbound authenticated connector), they are identical, including the smart host setting.  I've also checked to make sure EHS lists the external public IP's of both connectors as valid relay hosts.

So, let's call this one a "selective" SMTP protocol event sink problem.  :-)

Could still be a DNS issue, but limited to NDR's and journaled email, and only on ONE SMTP connector?

Anybody have any ideas?
Comment
Watch Question

David BeveridgeLinux Systems Admin
CERTIFIED EXPERT

Commented:
<> is used as the from address in an NDR message.
So what you are looking at in those logs is the NDR itself being delivered.

Author

Commented:
Not an NDR, it is an envelope journal in the queue.
This one is on us!
(Get your first solution completely free - no credit card required)
UNLOCK SOLUTION

Gain unlimited access to on-demand training courses with an Experts Exchange subscription.

Get Access
Why Experts Exchange?

Experts Exchange always has the answer, or at the least points me in the correct direction! It is like having another employee that is extremely experienced.

Jim Murphy
Programmer at Smart IT Solutions

When asked, what has been your best career decision?

Deciding to stick with EE.

Mohamed Asif
Technical Department Head

Being involved with EE helped me to grow personally and professionally.

Carl Webster
CTP, Sr Infrastructure Consultant
Empower Your Career
Did You Know?

We've partnered with two important charities to provide clean water and computer science education to those who need it most. READ MORE

Ask ANY Question

Connect with Certified Experts to gain insight and support on specific technology challenges including:

  • Troubleshooting
  • Research
  • Professional Opinions
Unlock the solution to this question.
Join our community and discover your potential

Experts Exchange is the only place where you can interact directly with leading experts in the technology field. Become a member today and access the collective knowledge of thousands of technology experts.

*This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

OR

Please enter a first name

Please enter a last name

8+ characters (letters, numbers, and a symbol)

By clicking, you agree to the Terms of Use and Privacy Policy.