Spam Filter ISP Support Forum

  New Posts New Posts RSS Feed - Connection refused by server, messages lost
  FAQ FAQ  Forum Search   Register Register  Login Login

Connection refused by server, messages lost

 Post Reply Post Reply
Author
gillonba View Drop Down
Newbie
Newbie


Joined: 30 April 2008
Status: Offline
Points: 33
Post Options Post Options   Thanks (0) Thanks(0)   Quote gillonba Quote  Post ReplyReply Direct Link To This Post Topic: Connection refused by server, messages lost
    Posted: 12 January 2010 at 12:45pm
We recently moved our anti-spam servers to a new location and IP, with everything working smoothly, with the exception of our biggest client.  The client in question is running Exchange 2007 with hub transport rules limiting the IP addresses that it will accept SMTP requests from.  Unfortunately, the hub transport rules were not updated, and for a time messages like this were showing up in the logs:
 
01/11/10 12:36:44:480 -- (4028) Sending email from <sender> to <recipient> --
01/11/10 12:36:54:886 -- (4028) 5.7.1 Client was not authenticated --  - forwarding to:<clientmailserver> - will try forwarding to <clientaltmailserver>
01/11/10 12:36:54:902 -- (4028) EMail from: <sender> to: <recipient> --  was returned to sender - server error - Already connected.
01/11/10 12:37:05:136 -- (4028) There was an error sending the NDR: 5.7.1 Client was not authenticated --
01/11/10 12:37:05:136 -- (4028)  - forwarding to:<clientaltmailserver> - server error - Already connected.

More unfortunately, and possibly a serious problem for us is that it appears the undeliverable messages were lost for ever, so that once the hub transport rules were updated, all the old e-mails were still missing and unrecoverable.  On top of that, it does not appear that a notification was returned to the sender.  This is a problem for us.  Is it possible there is a setting I am missing?  Should there be a queue of these undeliverable messages somewhere?  Or are messages lost by design?
Back to Top
Neolisk View Drop Down
Newbie
Newbie


Joined: 13 July 2009
Location: Toronto, ON
Status: Offline
Points: 27
Post Options Post Options   Thanks (0) Thanks(0)   Quote Neolisk Quote  Post ReplyReply Direct Link To This Post Posted: 13 January 2010 at 4:11pm
If you did not setup a database to quarantine them, I believe the answer is 'lost by design'.


Edited by Neolisk - 13 January 2010 at 4:11pm
Back to Top
gillonba View Drop Down
Newbie
Newbie


Joined: 30 April 2008
Status: Offline
Points: 33
Post Options Post Options   Thanks (0) Thanks(0)   Quote gillonba Quote  Post ReplyReply Direct Link To This Post Posted: 13 January 2010 at 5:18pm
We DO have a quarantine database, and actual spam is preserved, as expected.  The issue was with messages as they are being relayed.  Rather ironically, the spam was preserved while the legitimate messages were being lost.
Back to Top
LogSat View Drop Down
Admin Group
Admin Group
Avatar

Joined: 25 January 2005
Location: United States
Status: Offline
Points: 4065
Post Options Post Options   Thanks (0) Thanks(0)   Quote LogSat Quote  Post ReplyReply Direct Link To This Post Posted: 13 January 2010 at 5:30pm
gillonba,

The error "5.7.1 Client was not authenticated" in the log above appears to actually be the error that SpamFilter encounters when it attempts to forward emails to your destination SMTP server. It thus appears that your SMTP server is rejecting all emails from SpamFilter.

Without seing all your logs this is going to be just guessing, but this may be because your SMTP Server is forcing SMTP Authentication, and had the old IP address of your SpamFilter server in some sort of whitelist that allowed SpamFilter to forward it emails without authentication. Now that you moved SpamFilter to a new IP address, this new IP may not be allowed by your SMTP server to send emails without authentication.

If this is not the case, could you please zip and forward us about an hour's worth of SpamFilter's activity logfiles to support @ logsat.com? Please include as much information as you can about your destination SMTP server so we can get an idea of what may be happening.
Roberto Franceschetti

LogSat Software

Spam Filter ISP
Back to Top
gillonba View Drop Down
Newbie
Newbie


Joined: 30 April 2008
Status: Offline
Points: 33
Post Options Post Options   Thanks (0) Thanks(0)   Quote gillonba Quote  Post ReplyReply Direct Link To This Post Posted: 13 January 2010 at 6:03pm
LogSat, thank you, that was part of the problem, but we had that resolved before I posted.  The destination e-mail server was an Exchange 2007 server with hub transport rules that were preventing it from accepting e-mail from the new IP.  Updating the hub transport rules did indeed allow it to receive messages as expected.  But that's not what got me in hot water.

The problem was that after the connection was refused, the messages were _lost_ and we could not recover them.  Once the hub transport rules were updated, new messages were able to be delivered, but the old ones appear to be gone for ever.  THAT is the problem, and that's what I'm trying to find a solution for.  Thank you for your help
Back to Top
yapadu View Drop Down
Senior Member
Senior Member


Joined: 12 May 2005
Status: Offline
Points: 272
Post Options Post Options   Thanks (0) Thanks(0)   Quote yapadu Quote  Post ReplyReply Direct Link To This Post Posted: 13 January 2010 at 8:17pm
Our spamfilter implementation is setup so that if the server we are forwarding to (exchange in your case) returns a permanent error message the message is returned to sender.

If we were forwarding the message along, it is obviously not spam so it would not be placed into quarantine.

Since the server we tried to forward to returned a permanent failure message, it sends and NDR to the sender since we can't deliver it.

From the logs you included above, that seems to be what is happening as well.  The message was returned to sender.
Back to Top
LogSat View Drop Down
Admin Group
Admin Group
Avatar

Joined: 25 January 2005
Location: United States
Status: Offline
Points: 4065
Post Options Post Options   Thanks (0) Thanks(0)   Quote LogSat Quote  Post ReplyReply Direct Link To This Post Posted: 13 January 2010 at 11:00pm
If the remote SMTP server is unavailable, offline, or rejects connection attempts with either a 400 SMTP error code (which indicates a temporary error condition per RFC), then SpamFilter will by default queue the emails to be delivered, and will automatically re-attempt to deliver them every few minutes until the server is back online. If the SMTP server instead rejects connections from SpamFilter with a 500 SMTP error code (which per RFC indicates a permanent error condition, such a non-existing user, mailbox full etc), then SpamFilter will not queue the email and will instead send a NDR to the sender to inform them of the problem.

If SpamFilter needs to send an NDR, by default it will forward the NDR for delivery to the destination SMTP server. From the logs, it does unfortunately appear that since the Exchange server was requiring SMTP authentication, even the NDR emails were being rejected, so it's very possible they were not delivered either. If using the default settings in SpamFilter, and Exchange was rejecting the messages with a 500 error code (indicating a permanent rejection), it is likely that the messages were dropped.

There are some settings in the SpamFilter.ini file which can alter this default behavior:

;Determines if SpamFilter should hold in the queue emails that were rejected by the destination SMTP server with an error in the 4xy range
QueueIfDestinationError400=true

 

;Determines if SpamFilter should hold in the queue emails that were rejected by the destination SMTP server with an error in the 5xy range
QueueIfDestinationError500=false

;Determines if SpamFilter should remove from the queue emails that could not be delivered to the destination SMTP server due to a "Read Timeout" (an NDR is sent if the email is removed from the queue)
DoNotQueueIfReadTimeout=false


Roberto Franceschetti

LogSat Software

Spam Filter ISP
Back to Top
gillonba View Drop Down
Newbie
Newbie


Joined: 30 April 2008
Status: Offline
Points: 33
Post Options Post Options   Thanks (0) Thanks(0)   Quote gillonba Quote  Post ReplyReply Direct Link To This Post Posted: 14 January 2010 at 9:37am
Thank you Roberto!  That should solve our problem
Back to Top
 Post Reply Post Reply
  Share Topic   

Forum Jump Forum Permissions View Drop Down



This page was generated in 0.828 seconds.