Thanks, Sailor21 and Rolf. I really was writing rubbish there. As you say, it's my mail client which is sending the traffic with the incorrect EHLO, nothing to do with Mercury.It has also 'spontaneously' (probably due to a reboot for an unconnected reason) fixed itself.

The client, incidentally, is Thunderbird. I'm not sure where the EHLO is set; can't find it in Thunderbird or Windows.

I did have 127.0.0.1 in hosts, but Sailor's post set me thinking, and in Thunderbird I've now replaced the domain name for Mercury with 127.0.0.1. My intent is that traffic will no longer go via the router, and it is in fact much faster.

 As suggested, thanks, I have whitelisted 127.0.0.1 and my local subnet.

I usually use my ISP to relay outgoing mail, to avoid yahoo, etc, taking exception to my residential range static IP, but occasionally I use MercuryE for large attachments or if the ISP is having problems. Today, my own MercuryE blacklisted me for an invalid HELO! This has never happened before, and I haven't changed anything - I'm using Mercury 4.72.

The rule that blacklisted me is one that I think I added - the HELO/EHLO must have a period in it. I have MercuryE set up to identify me using by fully qualified domain name (see below), but today it used the Windows machine name. Looking back at the logs to see what worked previously, I see that the dotted quad was used [192.168.0.50]

So, two questions if anyone can help, please:

 1. Why is MercuryE not using the greeting in mercury.ini?

 2. Why should MercuryE have changed from using the dotted quad to the machine name? (maybe a Windows Update? I'm using XP)

 I could take the rule out, or just use the ISP, but I'd like to know what's going on!

Thanks

 [Edited title to make thread more useful to anyone else - once I realised that this original post contained rather a lot of errors - see thread]

Could it in fact be a SMTP session between your email client and MercuryS that triggered the blacklisting? I'm pretty sure MercuryE does use the greeting in mercury.ini.

An IP address from a private network is not suitable as HELO greeting when communicating over the Internet, so you probably changed that yourself at some time. It wasn't Windows Update at least, it doesn't know that Mercury exists.

/Rolf

[quote user="Chris Bolton"]

I usually use my ISP to relay outgoing mail, to avoid yahoo, etc, taking exception to my residential range static IP, but occasionally I use MercuryE for large attachments or if the ISP is having problems. Today, my own MercuryE blacklisted me for an invalid HELO! This has never happened before, and I haven't changed anything - I'm using Mercury 4.72.[/quote]
I'm far from certain what is going on here; but I'm pretty confident that it was NOT MercE that threw that error.

[quote]The rule that blacklisted me is one that I think I added - the HELO/EHLO must have a period in it.[/quote]
I could be wrong; but it sounds to me like you're talking about a Transaction Filtering Rule, under MercS (see the "Compliance" tab), which presumably looks something like:

    H, "*.*" RSN, "501 Invalid HELO/EHLO greeting."

In fact, there is no place to even enter such a "rule" under MercE.

If my assumption is correct, then it is indeed MercS which is barfing on your sending system's invalid hostname, *NOT* MercE.  And in *that* case, it is the sending system which "suddenly changed", not the system running Mercury (well..  at least presuming that they are indeed two separate systems).

[quote]I have MercuryE set up to identify me using by fully qualified domain name (see below), but today it used the Windows machine name. Looking back at the logs to see what worked previously, I see that the dotted quad was used [192.168.0.50]
[MercuryE]
HELO : cjbolton.plus.com
[/quote]
What exactly are you quoting above?  Is that a snippet from a Session-Logging file?  If so, in which module (or modules) did you enable session logging?

[quote]So, two questions if anyone can help, please:

 1. Why is MercuryE not using the greeting in mercury.ini?[/quote]
We have not yet established that it's not.

A few more questions...

1. - Is the machine running Mercury dedicated to that task, or does it also serve as your general-purpose desktop PC -- particularly, the one upon which you run your mail client?

2. - Have you closely examined MERCURY.INI to confirm that the fully-qualified hostname is indeed entered correctly in the appropriate spot?  Typically, it should appear in at least two places; first, in the [General] section:

    [General]
    myname:          HOST.SLD.TLD    # Canonical name for this server

(This is the result of data you entered when you initially installed Mercury.  I believe you can also enter/update it from within Mercury at [ Configuration | MercuryE SMTP Client ].)

Secondarily, the hostname should also appear in the [Domains] section:

    [Domains]
    HOST: SLD.TLD
    HOST: HOST.SLD.TLD
    HOST: [111.222.333.444]
    DM=OTHER-DOMAINNAME: SLD2.TLD2

(This is the result of data you entered in Mercury at [ Configuration | Mercury core module... | Local domains }; and is re-editable via those pull-downs as well as directly in MERCURY.INI.)

[quote] 2. Why should MercuryE have changed from using the dotted quad to the machine name? (maybe a Windows Update? I'm using XP)[/quote]
Well, there's no telling what sort of crap MSFT will cram down your throat via Windows Update (which is why I have always refused to use it; I update my systems manually *after* determining if each specific update is both applicable to that system *and* desirable in general -- many of them AREN'T).  But even still, about the only way I can think of off the top of my head for any updates to the underlying machine to have an effect on this is if you have NOT explicitly entered the hostname in the above-mentioned places during install.setup of Mercury.

[quote] I could take the rule out, or just use the ISP, but I'd like to know what's going on![/quote]
As noted above, I really don't think this "rule" is the problem, or that it is occurring where you think it's occurring.  But we'll know more after you report on the questions I asked above.

Sorry, gents, I didn't make that very clear, obviously, and I also wrote that MercuryE was blacklisting when I meant MercuryS

I have Mercury running on a general purpose PC, and the mail client which sent the blocked mail is also on this PC. I will try with a different client PC; good point, thanks.

I have a rule in MercuryS as follows     H, "*.*", BSN, "554 Invalid HELO"    and this recently resulted in one of my own mails sent through MercuryE being rejected and MercuryS temporarily blacklisting my local IP. This didn't happen the previous time I used MercuryE. On investigating, the MercuryS logs showed that the EHLO that triggered the blacklist was the XP machine name, while the EHLO that was accepted previously was [192.168.0.1]. Here are my MercuryS logs:

T 20110328 203649 4d8f5ebd Connection from 192.168.0.50
T 20110328 203649 4d8f5ebd EHLO user281abc2f54
X 20110328 203649 4d8f5ebd 554 Invalid HELO
T 20110328 203649 4d8f5ebd Connection closed with 192.168.0.50, 0 sec. elapsed.
E 20110328 203658 0 Connection from 192.168.0.50 refused because of short-term restriction.

I agree neither of these is suitable for my machine to be using as EHLO, and I don't know why it's happening. In both the core module "Internet name for this system" and MercuryE "Introduce myself as" I have entered my domain name, cjbolton.plus.com  - this has been unchanged since I set Mercury up several years ago. This info is shown in the config screens and in the following extracts from mercury.ini (the MercuryE section was what I included in my first post)

[General]
myname:          cjbolton.plus.com    # Canonical name for this server

[MercuryE]
HELO : cjbolton.plus.com

[Domains]
cjbolton: cjbolton
cjbolton: cjbolton.plus.com
cjbolton: [212.159.73.44]

The rule is not the problem, as you say; it's just the mechanism by which my odd EHLO has been identified.

Hope this makes sense now; thanks for your help.

To avoid getting local IPs blacklisted when a local email client connects to MercuryS using whatever HELO it finds suitable you can whitelist and exempt from transaction filtering the private net range you use (192.168.0.0 - 192.168.0.255) in MercuryS connection control.

Note that the MercuryS log shows the HELO used by clients and servers that connect to Mercury, not the greeting that MercuryE will use when connecting to another mail server.

/Rolf 

[quote user="Chris Bolton"]
Sorry, gents, I didn't make that very clear, obviously, and I also wrote that MercuryE was blacklisting when I meant MercuryS[/quote]
OK, no problem.  I just wanted to be sure that we were all on the same page, so to speak, because it is important to keep straight the order of operations and the "path" of a given message through the delivery process, when attempting to troubleshoot an issue.

[quote]I have Mercury running on a general purpose PC, and the mail client which sent the blocked mail is also on this PC. I will try with a different client PC; good point, thanks.[/quote]
If you're running both Merc and the client on the same system, you will probably have the client set to "send to" the SMTP server (i.e., MercS) at IP 127.0.0.1 (i.e., the loopback interface).  So MercS in turn should see that as an "incoming connection" from that same address.  But the EHLO/HELO string it sees is still determined solely by the client, NOT Mercury.

[quote]I have a rule in MercuryS as follows     H, "*.*", BSN, "554 Invalid HELO"[/quote]
That looks fine.

[quote]and this recently resulted in one of my own mails sent through MercuryE being rejected and MercuryS temporarily blacklisting my local IP. This didn't happen the previous time I used MercuryE.[/quote]
But here you exhibit exactly the same sort of confusion I spoke of above...  At THAT point in the proceedings, MercE has not yet even seen the message in question; so it has absolutely nothing to do with this.

[quote]On investigating, the MercuryS logs showed that the EHLO that triggered the blacklist was the XP machine name, while the EHLO that was accepted previously was [192.168.0.1].[/quote]
So did you perchance change anything with the client, be that updating it to a newer version or changing the config in any way?  What about the underlying system itself?  Did you apply any patches/updates (including automagically via Windows Update) between when Merc worked as desired and when it started rejecting the EHLO/HELO?

[quote]Here are my MercuryS logs:[/quote]
Allow me to re-arrange an annotate these slightly, for clarity...

[quote]
(Log excerpt from March 02, 2011)
T 20110302 192228 4d604c6f Connection from 192.168.0.50
T 20110302 192228 4d604c6f EHLO [192.168.0.50]
T 20110302 192228 4d604c6f MAIL FROM:<address snipped> SIZE=8585697
T 20110302 192228 4d604c6f RCPT TO:<address snipped>
T 20110302 192228 4d604c6f DATA
T 20110302 192233 4d604c6f DATA - 116036 lines, 8585697 bytes.
T 20110302 192233 4d604c6f QUIT
T 20110302 192233 4d604c6f Connection closed with 192.168.0.50, 5 sec. elapsed.

(Log excerpt from March 28, 2011)
T 20110328 203649 4d8f5ebd Connection from 192.168.0.50
T 20110328 203649 4d8f5ebd EHLO user281abc2f54
X 20110328 203649 4d8f5ebd 554 Invalid HELO
T 20110328 203649 4d8f5ebd Connection closed with 192.168.0.50, 0 sec. elapsed.
E 20110328 203658 0 Connection from 192.168.0.50 refused because of short-term restriction.
[/quote]
This confirms what we've both been saying...  At some point between March 02 and March 28, *something* caused the mail client (i.e., whatever program you use to read and compose e-mail messages) to change the way it identifies itself when sending mail.  While the earlier form of the ID is strictly "legal" per RFC2821, it's generally frowned upon; so maybe that is the underlying "why" some intervening update to either the mail client or the operating system caused that behavior to change?

Also...  While not necessarily relevant to your immediate problem, I'm a little concerned that this machine is apparently identifying itself to itself by its "external" IP address.  That IP literal really should read: "[127.0.0.1]".  Do you have an entry in your local "hosts" file which looks like this:

    127.0.0.1        localhost

???

If not, I'd suggest adding such ASAP.  Who knows..?  It might even fix your HELO/EHLO problem (tho' I rather doubt that).

[quote]I agree neither of these is suitable for my machine to be using as EHLO, and I don't know why it's happening.[/quote]
Well, as I mentioned above, use of an IP Literal IS "legal"; it's just considered "poor form" in some quarters.

[quote]In both the core module "Internet name for this system" and MercuryE "Introduce myself as" I have entered my domain name, cjbolton.plus.com  - this has been unchanged since I set Mercury up several years ago. This info is shown in the config screens and in the following extracts from mercury.ini (the MercuryE section was what I included in my first post)[/quote]
That's all well and good, but completely irrelevant.  In both cases, those parameters apply ONLY to:

a.)  how Mercury (via either MercE or MercC) identifies itself when sending outgoing mail that has already passed through MercS.  

b.)  the "220- ..." greeting message that MercS sends to the client immediately upon seeing an incoming connection.

(Hmmm...  On further thought:  It *may* also come into play when pulling incoming mail from an external POP3 server via the MercD Distributing POP3 Client; but since I don't use that module, I can't be sure.)

[quote]The rule is not the problem, as you say; it's just the mechanism by which my odd EHLO has been identified.

Hope this makes sense now; thanks for your help.[/quote]
You're quite welcome.  Hopefully the above will be helpful; but the upshot is, you need to be looking at the client program, not Mercury, for the solution.  In the meantime, as Rolf pointed out, you can whitelist the localhost to exempt it from Transaction Filtering, and thus side-step the whole issue.