Connection refused by server, messages lost
Printed From: LogSat Software
Category: Spam Filter ISP
Forum Name: Spam Filter ISP Support
Forum Description: General support for Spam Filter ISP
URL: https://www.logsat.com/spamfilter/forums/forum_posts.asp?TID=6790
Printed Date: 05 February 2025 at 11:54am
Topic: Connection refused by server, messages lost
Posted By: gillonba
Subject: Connection refused by server, messages lost
Date 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?
|
Replies:
Posted By: Neolisk
Date 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'.
|
Posted By: gillonba
Date 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.
|
Posted By: LogSat
Date 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
http://www.logsat.com" rel="nofollow - LogSat Software
http://www.logsat.com/sfi-spam-filter.asp" rel="nofollow - Spam Filter ISP
|
Posted By: gillonba
Date 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
|
Posted By: yapadu
Date 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.
|
Posted By: LogSat
Date 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
http://www.logsat.com" rel="nofollow - LogSat Software
http://www.logsat.com/sfi-spam-filter.asp" rel="nofollow - Spam Filter ISP
|
Posted By: gillonba
Date Posted: 14 January 2010 at 9:37am
|
Thank you Roberto! That should solve our problem
|
|