> Hi, there, I installed the free version of Mercury 32 that came with
> Xampp (a suite of free tools for building an apache/php server). I'm
> going to be testing/developing a web application (drupal) on my local
> machine). Drupal requires that the server have smtp (for password
> authentication, etc). In fact, you can't even install Drupal locally
> unless you have an SMTP server running. Hence, my reason for Mercury
> 32.

Ok,

> I am pretty clueless about what exactly I need to do. Can someone
> point me to the steps? When I open the Mercury 32 control Panel, I see
> windows for SMTP server and SMTP client  (and IMAP server, etc).
> Success would probably mean that I can send a message which would be
> sent through Mercury to an outside web address (gmail, etc). If I
> choose File --> Send email message, I get a email send window, with
> postmaster@localhost as my sending address. I try a test message to
> the outside; no success. (I even checked gmail's spam filter).

What you really need to do is verify the setup, XAMPP does not do a very good job of setting up Mercury by default.  

1.    MercuryS is used to receive the mail from an outside source and you need to turn on session logging to see if the mail is being received from Drupal.

2.    Next, XAMPP sets up MercuryE as the outbound client by default.  Any port 25 blocking will cause a failure.  If you do not have a fixed IP address then most major servers will reject your connection as spam.  You need to convert to MercuryC to relay through your ISP's SMTP host to send the mail.

>
> I am on Vista. Do I need to create an exception on the Windows Firewall. Which port? Is that the only problem?

MercuryE and MercuryC both use port 25 for outbound mail.  MercuryS uses port 25 inbound but since it's only receiving a local connection from Drupal this should not be affected by the firewall.

> Do I need  to create a local user name for SMTP?

Yes, there must be a postmaster local account.

>
> Is File --> Send email message the best mechanism for verifying that a
> message has gone through?  What about doing smtp on the command line?

I do telnet to the host to verify.  Here's a sample session.  The ones with 250 and 354 are from the server, the others I typed in.

Start | Run telnet svl78zxa97.lmms.lmco.com 25

You will see something like the following.  The ones with the numbers are from the server, the others I typed in.

<< 220 ESVCS.lmms.lmco.com Mercury/32 v3.01 SMTP/ESMTP server ready.
>> EHLO SVL78ZXA97
<< 250-ESVCS.lmms.lmco.com Hello SVL78ZXA97; ESMTPs are:
<< 250-TIME
<< 250-SIZE 5000000
<< 250-8BITMIME
<< 250-AUTH CRAM-MD5
<< 250 HELP
>> MAIL FROM:<support@stephens.sj.scruznet.com> SIZE=517
<< 250 Sender and size (517) OK - send RCPTs.
>> RCPT TO:<support@stephens.sj.scruznet.com>
<< 250 Recipient OK - send RCPT or DATA.
>> DATA
<< 354 OK, send data, end with CRLF.CRLF
>> From: "Thomas R. Stephenson" <support@stephens.sj.scruznet.com>
>> To: support@stephens.sj.scruznet.com
>> Date: Wed, 2 Feb 2000 11:35:28 -0800
>> Subject: Test #4
>>
>> Mail body
>> .
<< 250 Data received OK.
>> QUIT

> (Unfortunately, the Mercury local online help is in hlp format and
> incompatible with Vista. (I tried downloading the hlp reader for Vista
> from MS, with no success).

You might want to upgrade the the latest version.

Thanks, so it was just the lack of the number 521 at the beginning of the message that was the problem.

Cheers, Gordon

[quote user="bryroller"]

As a courtesy to our users (in a K-12 educational environment) I have had postmaster errors enabled. This, in turn, automatically generates delivery failure notifications to senders... all is good - right?

Wrong in today's environment.  You should be using the reject at MercuryS to ensure that only the sending server gets the ejections.  If you receive and then bounce you are bouncing to what could very easily be a forged address contained in the RFC 2822 message body.

Well... all was good - I occasionally check things here using mxtoolbox.com (most helpful, BTW) and today I find that I am listed with backscatter.org :-(...

Not that big a deal since this blacklist has a huge false positive rate that there are very few users.  

 
From what I gather, having the delivery failure errors enabled is probably what has me listed. I like having the failures give the end user some idea as to the error(s) of their way(s) but don't know how I can keep these failure notifications from being delivered off campus.

Correct, the mail was probably accepted by some SMTP server supporting your domain and then bounced as being a non-local user creating what is called backscatter.  If you are receiving via MercuryD you should never bounce the message but simply send it to the default user for handling manually.

 
I use Mercury/32 as a relay to a back-end server and don't really want to keep up a manual list of 300+ users (synonyms) and wonder if there is a better (or any) way of keeping the delivery failures enabled and not continue to be listed on backscatter.org?

The back-end server should never bounce mail received from Mercury/32 but send it to a postmaster account for manual processing.

TIA 

[/quote]

Hi yes we are using SMTP authentication in the AUTH Password file

[quote user="Ellie Kennard"]Is It istevenkennard.com or just stevenkellard.com ?"[/quote]

My typo.

[quote]Note the spelling of the second email where in reality you had actually written stevenkennard.com - so how could THAT have happened? Pegasus? Transmission? Mercury?[/quote]

Corrected within 20 seconds, but not before the email was sent.  :(

I assume that you are getting all mail via MercuryS.

The first thing that comes to mind is that the RCPT TO: address is not the same as the From: address. 

The second is that you deleted the user with Mercury/32 running and did not use the CTRL+Manage local users and/or restart Mercury so that the address was not deleted from memory.

Changing of the IP address should have no affect on this.

Thanks,

 1- But, in my mail client I can configure if I want that mails remind x days in my ISP server, for me this option is essential because my boss sometimes works via webmail of the ISP server. I could create a clone account in the ISP server, but I would like if i can configure this via mercury mail.

2- Ok, that's ok, I will do it through my mail client. 

thanks

Can one get a temporary license to allow for testing Mercury/32 running as a service? 

If domain.de is an external domain then you should not have it listed in "Local Domains".

You can set a local user for each MercD pop account to deliver to, or set an alias for the you@domain.de address (or get your own domain name [:)])

David has reported having fixed the MercuryX problem, and we the testers will most likely receive 4.73 RC within a week with additional issues addressed.

Rolf's HttpServer now also works with Mercury running as a native service.

Watch this space for more news.

Have a nice weekend.

Must have missed something as I now have the vbscript firing as expected.  Sorry for the false alarm.

E 20090915 121135 a94 Error connecting to RBQITEXCHVS01.XCTC.CTC.NHS.UK.

This can be caused by a number of reasons.

1.  Port 25 is being blocked by your ISP and this is not your ISPs SMTP relay host.

2.  Port 25 is being blocked by your firewall.

3.  Mercury/32 is being blocked by your firewall.

As a test try using Start | Run telnet tstephenson.com 25 to verify that you get the answer 220 tstephenson.com ESMTP server ready.  If you do not then port 25 is being blocked.  BTW I cannot connect to RBQITEXCHVS01.XCTC.CTC.NHS.UK either.

Well, the "JFNOFILTER" flag seem to be set by Mercury on DF's for a reason.

It may have other effects when used in Netware or Pmail integrated scenario's, neither of which I am very familiar with.

It may indeed be a feature rather than a bug as it seems to be intentional behaviour.

Maybe some of the Beta testers with a better overview could comment?

First off - thanks to both of you for really helpful replies. Let me see if I can clarify some things...

ASSP is basically a proxy server that filters incoming mail for spam and receives all outgoing so it can whitelist all addresses mails are being sent to. This has the big advantage that addresses users send mails to are automatically whitelisted for a year. As for the configuration - I'm aware that it is somewhat complicated, but this is the official configuration recommended by the ASSP documentation when ASSP and Exchange are running on the same machine, which they do in my case.

@dilberts_left_nut: I'm currently only worried about Mercury as a possible cause for an open relay. Yet I see your point that Mercury itself cannot actually be the problem.

@Thomas R. Stephenson: Thanks for the advice - I'll add the refuse entry. From your recommendation I take it that entries that are higher up supersede ones below, right?

Taken together, I take your two posts to say that Mercury probably is not the cause of my problem. That means I'll turn to the Exchange server and recheck that one...

Thank you so much!

Cheers,
Stefan.

Good point!  I hadn't thought of that :-)  I wondered why the reports had stopped!  So, I will have to reduce the reporting period, if I do a daily restart.  I have now set it to 23 hours, which will lose some of the count.  I wonder if it will handle reporting periods that include fractional hours.

Gordon

For maintenance of aliases I need to run sometimes the Mercury Nsynonym.exe tool.

This works fine on the Win2000-client, but is not working on the WinXP-client.

Any suggestions ?

Upgrade the client to v4.91??

To make this work you need to have MercuryE running in the domain1.com instance of Mercury to perform the delivery to the anotherdomain.com instance. If you are using MercuryC to send via an external server the local 192.168.1.100 address will not be found.

You should perhaps have a look at the WSMTPEx.exe program instead? See this thread:

/Rolf 

[quote user="Alar.Pandis@mtk.ut.ee"]

Forgot. ASSP is working together with Mercury/32.
Alar.

[/quote]

And against you, it would seem.

Mercury will not change the headers, only add a Recieved: line.

ASSP is my prime suspect, you should turn off ASSP and see if that solves the problem (of growing Ref header).

A valid message body must not have any single line greater than 1000 characters, so once the line exceeds this, it is no longer a valid message, which would explain why Merc can not process it correctly.

Sorry,

As Chris Bolton said, my  "myinternaldomain.com" is an internal domain that I had made up myself, not  a real "from" adress. So I use my external domain with the parameters of my ISP .

[quote user="GordonM"]A message was recently generated/received that had 80 characters in the local part, which is longer than the RFC seems to suggest.[/quote]

Well that's fine.  Although it says the local part should not exceed 64 characters, it also says  [quote]Every implementation MUST be able to receive objects of at least these sizes.[/quote]

It seems to me that Mercury is adhering to the standards.