They've just back to me - last time they could send mail was March 6th.

That explains it.

Thanks again for helping me sort this out, it was really frying my brain.

Hi folks

I have a problem that cropped up last week.

I have MercuryS and MercuryI modules installed (SMTP and IMAP).

MercuryS is configured to reject mail from all IP addresses apart from those we specify explicitly i.e. MessageLabs server addresses and internal network machines. Strict relaying controls are in place - only users who use SMTP authentication can relay mail via IMAP. I have a SMTP username/password list setup in Mercury and this has worked fine for a long time.

Suddenly users are getting 'address rejected' error messages when trying to send mail. They can connect and receive mail without a problem. When I tested this tonight my mail client (Windows Mail on Vista) gave the following message:

Subject 'test', Account: '82.69.48.10', Server: '82.69.48.10', Protocol: SMTP, Server Response: '520 Connection not authorised from this address.', Port: 25, Secure(SSL): No, Server Error: 520, Error Number: 0x800CCC61

When I add my IP address to Connection Control and Allow it, the mail passes through. Something must have changed but I don't know what. Obviously, because the staff who connect do not have static IP addresses, I can't add them to the allowed list.

Any suggestions gratefully received

Thanks

That was a SMTP connection, though, not IMAP...

Anyway, it appears that the client didn't SMTP AUTH. To find out exactly what happens, create a MercuryS session log in Mercury (and remember to switch it off after you have completed the test).

/Rolf 

Subject 'test', Account: '82.69.48.10', Server: '82.69.48.10',

Protocol: SMTP, Server Response: '520 Connection not authorised from

this address.', Port: 25, Secure(SSL): No, Server Error: 520, Error

Number: 0x800CCC61

When I add my IP address to Connection Control and Allow it, the

mail passes through. Something must have changed but I don't know what.

Obviously, because the staff who connect do not have static IP

addresses, I can't add them to the allowed list.

I suspect that there are IP addresses getting added to the short term blacklist and then the users of that IP address is getting rejected by MercuryS.  You can test this by turning off all SMTP short term blacklisting.

Thanks for your replies.

Yes, you are right, it is a SMTP error message.

Here is what happens:

I start my mail client and retrieve my mail from my personal addresses (gmail, btinternet etc).

Next, I click on the IMAP account (the Mercury account apsarchaeology.co.uk) in the client and it downloads the headers for the new mail. I open a mail message and the entire message is downloaded and I can read it.

It is when I try to reply to the message that I see the error I quoted above.

I have session logging turned on by default for MercuryS (and for all the modules), but no log was created for any of the mail failures reported by the user who initially reported this, nor when I tested this last night.

Here is a view of the session log directory. My IMAP connection is highlighted. I tried to reply during that session. You can see that the next MercuryS session log is not recorded until 1 hour later (and it is not a log of the transaction I tried to send):

When I logged onto the server hosting Mercury last night when I was testing this I saw IP address rejection messages in the MercuryS window for my home IP address. I've searched the logs folder for authentication failures (I searched for my SMTP auth password in the sessions folder) and nothing was found. As I said above, when I allowed my address in the MercuryS connection control dialog, messages I sent from my IMAP account went through.

So, presumably, as Rolf says the client is not doing the SMTP AUTH. The people who use IMAP use either Outlook Express 6, Outlook 2007 and Windows Mail on XP and Vista.

When I checked the connection control list I made certain that my address was not in the refuse list before I added it. We don't have a 'blacklist' as such, or are you referring to the connection control 'refuse' entries?

If anyone has any further thoughts on this please post.

Thanks

[quote user="Greenman"]

It is when I try to reply to the message that I see the error I quoted above.

[/quote]

It is the MercS connection control that is rejecting you, so IMAP & POP3 is not effected.

[quote]

I have session logging turned on by default for MercuryS (and for all the modules), but no log was created for any of the mail failures reported by the user who initially reported this, nor when I tested this last night.

[/quote]

There should be rejection messages with your IP address in both the session logs and the general log.

[quote]

Here is a view of the session log directory. My IMAP connection is highlighted. I tried to reply during that session. You can see that the next MercuryS session log is not recorded until 1 hour later (and it is not a log of the transaction I tried to send):

When I logged onto the server hosting Mercury last night when I was testing this I saw IP address rejection messages in the MercuryS window for my home IP address. I've searched the logs folder for authentication failures (I searched for my SMTP auth password in the sessions folder) and nothing was found.

[/quote]

It's not getting far enough through the process to attempt authentication.

[quote]

As I said above, when I allowed my address in the MercuryS connection control dialog, messages I sent from my IMAP account went through.

[/quote]

The SMTP session really has nothing to do with your IMAP account.

Either you Connection Control entries have been set to block your IP address range by default, or you are triggering some Compliance Setting, or you have a tranflt.mer rule that is rejecting you.

[quote]

So, presumably, as Rolf says the client is not doing the SMTP AUTH. The people who use IMAP use either Outlook Express 6, Outlook 2007 and Windows Mail on XP and Vista.

[/quote]

Client should not matter.

[quote]

When I checked the connection control list I made certain that my address was not in the refuse list before I added it. We don't have a 'blacklist' as such, or are you referring to the connection control 'refuse' entries?

[/quote]

What are your connection control entries?

[quote]

If anyone has any further thoughts on this please post.

Thanks

Hi and thanks for the reply

I understand that it is MercuryS that is rejecting the connection attempt - the reason I gave this thread the title I did was because it was happening while I was using my IMAP account. Sorry for the confusion

The IMAP general and session logs show the following:

General log:
Connection from 86.153.85.22, Thu Apr 23 17:59:38 2009
Password failure, user 'greenman', from 86.153.85.22
greenman at 86.153.85.22: 61 sec. elapsed, connection closed Thu Apr 23 18:00:39 2009
Connection from 86.153.85.22, Thu Apr 23 18:00:39 2009
greenman at 86.153.85.22: 64 sec. elapsed, connection closed Thu Apr 23 18:01:43 2009
Connection from 86.153.85.22, Thu Apr 23 18:12:12 2009
greenman at 86.153.85.22: 1 sec. elapsed, connection closed Thu Apr 23 18:12:13 2009
Connection from 86.153.85.22, Thu Apr 23 18:21:10 2009
Connection from 86.153.85.22, Thu Apr 23 18:31:40 2009
greenman at 86.153.85.22: 2 sec. elapsed, connection closed Thu Apr 23 18:31:42 2009
greenman at 86.153.85.22: 771 sec. elapsed, connection closed Thu Apr 23 18:34:01 2009

Session log:
17:59:38.750: Connection from 86.153.85.22, Thu Apr 23 17:59:38 2009<lf>
17:59:38.765: << * OK apsarchaeology.co.uk IMAP4rev1 Mercury/32 v4.62 server ready.<cr><lf>
17:59:38.843: >> y08e CAPABILITY<cr><lf>
17:59:38.859: << * CAPABILITY IMAP4rev1 AUTH=PLAIN X-MERCURY-1<cr><lf>
17:59:38.859: << y08e OK CAPABILITY complete.<cr><lf>
17:59:38.921: >> 7s3h LOGIN "greenman" "SMTPpassword"<cr><lf>
17:59:38.921: << 7s3h NO Username or password incorrect.<cr><lf>
17:59:58.671: >> efwg LOGIN "greenman" "IMAPpassword"<cr><lf>
18:00:09.265: << efwg OK LOGIN completed.<cr><lf>
18:00:09.343: >> 1vma SELECT "INBOX"<cr><lf>
18:00:12.421: << * 71 EXISTS<cr><lf>
18:00:12.421: << * 0 RECENT<cr><lf>
18:00:12.421: << * FLAGS (\Deleted \Draft \Seen \Answered)<cr><lf>
18:00:12.421: << * OK [UIDVALIDITY 1194793930] UID Validity<cr><lf>
18:00:12.421: << * OK [UIDNEXT 3985] Predicted next UID<cr><lf>
18:00:12.421: << * OK [PERMANENTFLAGS (\Deleted \Draft \Seen \Answered)] Settable message flags<cr><lf>
18:00:12.421: << 1vma OK [READ-WRITE] SELECT completed.<cr><lf>
18:00:12.515: >> 44up UID FETCH 3933:* (BODY.PEEK[HEADER.FIELDS (References X-Ref X-Priority X-MSMail-Priority X-MSOESRec Newsgroups)] ENVELOPE RFC822.SIZE UID FLAGS INTERNALDATE)<cr><lf>
18:00:12.515: << * 20 FETCH (UID 3933 BODY[HEADER.FIELDS (References X-Ref X-Priority X-MSMail-Priority X-MSOESRec Newsgroups)] {2}<cr><lf>
18:00:12.515: << <cr><lf>
etc

So, Rolf is quite right - the SMTP AUTH is failing. I have checked the password thoroughly. When I was logged onto the server remotely while testing this I made sure my SMTP password was correct by using copy and paste to copy from the SMTP_Auth.pw file and pasting it into my IMAP connection properties dialog where it requests the Outgoing server password.

The password is visible in the original logs and they are correct for all users.

My connection control list is as follows (I stitched two pics together to make this which is why it looks odd):

The MercuryS general log shows the following entry:
E 20090423 180120 0 Connection from 86.153.85.22 refused because of restriction.

There are no entries in any of the MercuryS session logs that contain my IP address.

[quote user="Greenman"]

Hi and thanks for the reply

I understand that it is MercuryS that is rejecting the connection attempt - the reason I gave this thread the title I did was because it was happening while I was using my IMAP account. Sorry for the confusion

The IMAP general and session logs show the following:

General log:
Connection from 86.153.85.22, Thu Apr 23 17:59:38 2009
Password failure, user 'greenman', from 86.153.85.22

Session log:
17:59:38.750: Connection from 86.153.85.22, Thu Apr 23 17:59:38 2009<lf>
17:59:38.765: << * OK apsarchaeology.co.uk IMAP4rev1 Mercury/32 v4.62 server ready.<cr><lf>
17:59:38.843: >> y08e CAPABILITY<cr><lf>
17:59:38.859: << * CAPABILITY IMAP4rev1 AUTH=PLAIN X-MERCURY-1<cr><lf>
17:59:38.859: << y08e OK CAPABILITY complete.<cr><lf>
17:59:38.921: >> 7s3h LOGIN "greenman" "SMTPpassword"<cr><lf>
17:59:38.921: << 7s3h NO Username or password incorrect.<cr><lf>
17:59:58.671: >> efwg LOGIN "greenman" "IMAPpassword"<cr><lf>
18:00:09.265: << efwg OK LOGIN completed.<cr><lf>

[/quote]

Your client should not be sending your SMTP credentials to the IMAP server.

[quote]

So, Rolf is quite right - the SMTP AUTH is failing.

[/quote]

No, see below.

[quote]

The MercuryS general log shows the following entry:
E 20090423 180120 0 Connection from 86.153.85.22 refused because of restriction.

There are no entries in any of the MercuryS session logs that contain my IP address.

[/quote]

Your IP address is NOT covered by any 'Allow' entries and falls into your 'Refuse' range, so is getting rejected (before you even get the chance to authenticate).

Seriously, I don't understand.

This is how it has always been setup and it has worked until very recently.

The SMTP credentials are those specified in the Mercury SMTP_Auth.pw file. I understood that these credentials were required to allow mail to be relayed through the server where the sender's IP address did not exist in the allowed list.

If the client should not be sending the user's SMTP authorisation to the IMAP is there a problem with the client? Most of the connection records I looked at only had the required login details which allowed the initial connection. They did not also have the SMTP authorisation code.

So what do I need to do? I have no idea what is happening. If emails I send are being rejected by Mercury because my IP address is not on the allow list, and the SMTP authorisation code is not being sent to the server, what is the solution?

How should this work?

[quote user="Greenman"]

Seriously, I don't understand.

This is how it has always been setup and it has worked until very recently.

[/quote]

Something must have changed recently.

[quote]

The SMTP credentials are those specified in the Mercury SMTP_Auth.pw file. I understood that these credentials were required to allow mail to be relayed through the server where the sender's IP address did not exist in the allowed list.

[/quote]

To even connect to the SMTP server, your IP must be either NOT covered by a 'Refuse' range, OR have a "tighter" 'Allow' range, which you do not look to have.

 [quote]

If the client should not be sending the user's SMTP authorisation to the IMAP is there a problem with the client? Most of the connection records I looked at only had the required login details which allowed the initial connection. They did not also have the SMTP authorisation code.

[/quote]

What client are you using, that seems odd behaviour.

[quote]

So what do I need to do? I have no idea what is happening. If emails I send are being rejected by Mercury because my IP address is not on the allow list, and the SMTP authorisation code is not being sent to the server, what is the solution?

How should this work?

[/quote]

You should either add an 'Allow' entry for your (and your users) IP address (or range) or remove your 'Refuse' entry.

Thanks a lot for your reply

It is the allow/refuse range of addresses that I am confused about.

When I initially set this up I only had the allow range set up. The server then received mail from an address outside the allow range. After posting here about this I was advised to set up a 'refuse' range that included all ip addresses. I set up IMAP after that and it worked.

If I remove the 'refuse' range of addresses will Mercury begin accepting mail for our domains from anyone who connects? We want to avoid this, and is the main reason we use MessageLabs. I know that Sebby said that the address was probably cached but I'd like confirmation if you can give it.

The only thing that has changed to my knowledge is that new MS updates have been installed. However, they were installed and the server rebooted over a week ago, so I doubt they are the cause. Nothing has been installed on this server for months. I am at a loss.

My home client is Windows Mail on Vista Ultimate.

Thanks again for your help with this.

Added:

I can't allow the user's addresses because they don't have static IP addresses.

[quote user="Greenman"]

Thanks a lot for your reply

It is the allow/refuse range of addresses that I am confused about.

When I initially set this up I only had the allow range set up. The server then received mail from an address outside the allow range. After posting here about this I was advised to set up a 'refuse' range that included all ip addresses.

[/quote]

Yes, but you have neglected an 'Allow' entry for your own IP address (86.153.85.22)

[quote]

I set up IMAP after that and it worked.

[/quote]

Again, IMAP will work regardless of the fact that you are banned by the SMTP server.

[quote]If I remove the 'refuse' range of addresses will Mercury begin accepting mail for our domains from anyone who connects?

[/quote]Yes

[quote]We want to avoid this, and is the main reason we use MessageLabs. I know that Sebby said that the address was probably cached but I'd like confirmation if you can give it.

The only thing that has changed to my knowledge is that new MS updates have been installed. However, they were installed and the server rebooted over a week ago, so I doubt they are the cause. Nothing has been installed on this server for months. I am at a loss.

My home client is Windows Mail on Vista Ultimate.

Thanks again for your help with this.

[/quote]Maybe your home IP address has changed

[quote]

Added:

I can't allow the user's addresses because they don't have static IP addresses.

[/quote]

Then you are buggered.

You either need to allow a range that coveres the dynamic addresses or else you are treated like everyone else you have banned with the refuse range, which is, you cannot connect to the SMTP server.

EDIT: Excellent, the forum accepts 'buggered' but not 'dick' [:#]

Thanks a lot for all your help with this.

I really did not realise that sending mail from an IMAP connection would be treated differently and that the credentials supplied would not be recognised.

Have a very pleasant weekend.

Cheers and ***** beers ;)

Greenman

[quote user="Greenman"]

Thanks a lot for all your help with this.

I really did not realise that sending mail from an IMAP connection would be treated differently

[/quote]

 Again, sending uses your SMTP settings and has nothing whatsoever to do with your IMAP (or POP3) settings.

[quote]

and that the credentials supplied would not be recognised.

[/quote]

The Connection Control entries you have are rejecting your IP address immediately, your client has no opportunity to even supply your credentials.

[quote]

Have a very pleasant weekend.

Cheers and ***** beers ;)

Greenman

I do understand but you also need to take on board the fact that this was working fine until very recently. The configuration of Mercury/32 has not changed in a long time. The last major change was when we upgraded to the new version and that went so smoothly that nothing need to be done after the upgrade was completed.

I know that something must have changed but I have absolutely no idea what this may be. I am the only person who administers our servers and I keep a diary of all configuration changes (well, most of them, depends on how busy I am...)

This is quite frustrating.

Still, the good thing about this is that I (once again) understand a little more about this, and I truly appreciate you spending the time to help me understand.

Cheers!

You will probably find that your users weren't relaying through your server.  Some ISPs use transparent proxies to intercept port 25 requests to divert them through their own servers.

[quote user="PaulW"]You will probably find that your users weren't relaying through your server.  Some ISPs use transparent proxies to intercept port 25 requests to divert them through their own servers.
[/quote]

Hi Paul, thanks for the information.

I've looked this up and as far as I can tell transparent SMTP proxies still require authentication before they will accept a message for transmission.

Since this has started, and on DLN's advice, I have added the IP addresses of the remote users to the SMTP allow list.

I now understand this a lot better than I did and and consequently am even more confused than I was as to why this was working.

Thanks again to everyone for their help with this [Y]

[quote user="Greenman"]I've looked this up and as far as I can tell transparent SMTP proxies still require authentication before they will accept a message for transmission.[/quote]

Freeserve/Wanadoo used to do this but never required authorisation if you were using their connection.  I don't have access to them anymore to check if that's still the case, but it should be easy to tell from the headers if you have one of these complete emails

[quote]I now understand this a lot better than I did and and consequently am even more confused than I was as to why this was working.[/quote]

:)

Maybe the IP range your ISP gives out changed?

You have an allow range for 85.x.x.x and your connecting IP was 86.x.x.x

[quote user="dilberts_left_nut"]

Maybe the IP range your ISP gives out changed?

You have an allow range for 85.x.x.x and your connecting IP was 86.x.x.x

[/quote]

Thanks for the suggestion. 

All the allow ranges you see in the image that appear before the refuse entry are the IP addresses of the MessageLabs (ML) servers. These are the addresses ML use to deliver mail to Mercury/32. I have gone through some of the IMAP session logs from the start of February and checked the IP addresses of the connecting hosts (as these same addresses would have been used to send mail through Mercury/32 too) - none are in the allowed range as defined on the MercuryS Connection control page.

With regard to the ISP providing the SMTP proxy - I assume this would be the ISP from the connecting host. Both I and the other person who has been connecting to Mercury/32 server on our network use different ISP's, and the work ISP is also different - three ISP's altogether.

@Paul

Here is a set of headers from an email I sent last June:

Received: from spooler by apsarchaeology.co.uk (Mercury/32 v4.52); 12 Jun 2008 17:51:25 +0100
X-Envelope-To: <greenman@apsarchaeology.co.uk>
Return-path: <greenman@apsarchaeology.co.uk>
Received: from Blood (86.150.115.64) by apsarchaeology.co.uk (Mercury/32 v4.52) with ESMTP ID MG00024A;
   12 Jun 2008 17:51:22 +0100
Message-ID: <351928F17919475B953D542F43DFF80C@Blood>
From: "Greenman" <greenman@apsarchaeology.co.uk>
To: "\"HTL VPN Users\"" <greenman@apsarchaeology.co.uk>
Subject: Please try the VPN
Date: Thu, 12 Jun 2008 17:51:10 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative;
 boundary="----=_NextPart_000_000A_01C8CCB4.E5C917C0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5512
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512
X-PMFLAGS: 570950016 0 1 YAJBI0AX.CNM

As you can see, this was successfully sent from my home PC through Mercury/32. The IP address is not in the allow range.

This sort of thing fries my brain...