[quote user="peterelliott11"]Right then, still doing it.

 Here is the details out of the Mercury.Ini file

 [MercuryC]
Host : smtp1.mail.com
Failfile : C:\MERCURY\Mercury\FAILURE.MER
HELO : Peter Elliott
Poll : 30
Scratch : C:\MERCURY\scratch
ReturnLines : 15
Timeout : 30
ESMTP : 1
SMTP_Username: peter.j.elliott:XXXBLANKEDXXX.com#mail.com
SMTP_Password: XXXBLANKEDXXX
POP3_Auth : 0
POP3_Host : pop1.mail.com
Logfile : C:\MERCURY\Logs\MercuryC\~y-~m-~d.log
Log_Verbose : 1
Session_logging : C:\MERCURY\Sessions\MercuryC
Session_logmode : 1

 On SMTP username, when I check the details in MercuryC after I shut it down and restart it, the #mail.com disappears and I have to re-enter it before the server sends messages out.

 However, the entry remains in the .INI file regardless, it's as if the program is 'forgetting' everything after .com[/quote]

I believe that Mercury/32 treats the # as a special comment character in the file.  Everything after the # is treated as a comment and so not used in the username.  I tested this and sure enough the #mail.com is trimmed from the username string.  That said I believe that most ISPs that use special characters in a username will generally allow you to use another character for the # (say like an underscore) that would perform the same task.

Thank you, again, Rolf.  Unfortunately, these are not fake usernames associated with my Mercury server.  They are usernames associated with one of the ISPs that I use.  They may or may not be fake.  The significance is that I see quite a lot of SPAM with multiple usernames (all starting with "g" as the first letter, presumably because the first letter of my usename starts with "g") at that ISP and it seems a good clue that the message is SPAM, as none of my correspondents use that ISP.

I looked at Graywall recently and gained the impression that I couldn't use it effectively, as quite a bit of my mail gets forwarded from another ISP to the one that I directly connect to with Mercury's Distributing POP3 Client.  I haven't tried SpamHalter so far, as I am having a fair amount of success with what I am currently doing.  Basically, I only accept mail without question from addresses that I have listed in Mercury's userlists and whitelist.  This allows me to have zero SPAM to my and my wife's user accounts.  Everything else is considered to be SPAM (which is deleted without any manual inspection) or potentially SPAM, which goes to a SPAM account.  It's the SPAM account that I have to work on to create rules to recognize real SPAM.  Of course, when people change their e-mail addresses without telling me, their messages end up as possible SPAM in the SPAM account.  This doesn't happen very often.

Gordon

[quote user="GLM"]Hello,

The MX servers of one of our main clients are experiencing a weird problem: our TCP connection at their port 25 is correctly established, but their 220 reply comes after a big delay (about 4 minutes). Of course, our MercuryE timeouts. I know there is a setting to control MercuryE's TCP/IP timeout. I am wondering if there is a setting to force MercuryE to wait ("indefinitely") for their first 220 reply.

Thanks in advance.

Gonzalo López Menéndez

GADD-GRUPO MEANA, S.A.[/quote]

Local mailboxes are stored in the location indicated by "Local mailbox directory path" in Configuration / Mercury core module. In that folder there will be one sub-folder for each local user.

Messages for non-local recipients will be in the Queue directory while being processed, but will not be stored on the server after that.

/Rolf 

Problem resolved..

Discovered that the C:\Temp directory was missing  so Clam was failing when trying to write to it. Restored the directory and all is well.

Thanks again

[quote user="Peter Strömblad"]There are no problems reaching:  from Sweden at the moment.[/quote]

Peter when I select the "Buy mercury online" button in http://community.pmail.com/pmail/MercuryPricing.aspx it goes to persephone and that's not correct since david changed the server to hera.

thanks rolf, finally i get the answer. it is because of the windows firewall. i turn off the firewall and then everything going to be ok. so thanks for the support. now i can sleep with one peace. any problem that will come out i will let the forums know about it. thanks a lot everybody.

Thomas,

The headers (helper and list unsubscribe) are in there ok.  It's the Mailing list Settings - Distribution - Signature File that does not show up on emails sent to the list if the originating email is sent as HTML vs plain text.

Again, I did not ugrade to latest version yet.

Thanks,

MP 

Great, thanks very much!

[quote user="David Winge"]

I moved the mail folders back to the old box and Mercury/32 is working fine, I removed it from the new server and did a fresh reinstall and it too seems to be working. In order to migrate from one server to the other, which files do I need to copy? I am also moving it from drive C: on one machine to D: on the other. Or if there is a FAQ somewhere on how to do this please point me that direction.

The only thing I do is copy the installation from one system to the other but I always use the C: drive.  If you are using the D: drive then everything pointing to the C: drive in the config files and mercury.ini needs to be changed.  The mercury.ini is pretty easy but there are a number of other config files that may need to be changed especially filters and MercuryD.  Also if the mailboxes are in c:\mercury\mail then there may also be pointers in the mailboxes pointing to the other drive letter as well.

Is there any reason you could not copy the installation to the c: drive?  If not I would try doing a completely new install only copying the user mailboxes and have everything else brand new.  If this works you can try copying the rules.mer and other config files one at a time until you are sure it's working.

Thank you kindly, David

[/quote]

I assume you are in fact using MercuryE (if you did relay through your Internet provider's SMTP server this would not be a problem).

In MercuryE configuration there is a field called  "Identify myself as". This is what will be sent to the receiving SMTP server in the HELO/EHLO greeting. The text you have there now ("WASD Asset Track Admin") is, as pointed out by DLN, not accepted by smtp.pct.edu. They require you to use a proper host name here, which would be something like "mail.yourdomain.com".

/Rolf

Thanks Rolf, that worked great.

Curt

According to my staff this works ok. We host hundreds of clients that we also serve with service and support, so for them this one does the trick. We're moving away from deploying Mercury or Exchange into the local environments due to the elevation of costs (man hours) to maintain multiple solutions. For those that want we host Exchange, file-servers, remote desktops  etc - but having an auto-print installed on a critical server is not something I'd recommend out of stability reasons. There is nothing worse than software that doesn't release resources, and no programmer locates all circumstances were bugs arise - so we tend to stick to a KISS principle, still.... 

Thanks for the input, good ideas are always fun to toss around.

error 1: It seems that the server you are connecting to is rejecting you based on your IP address. You may have to relay through you ISP's SMTP server (with MercC instead of MercE)

error 2: Looks like your SMTP client (MercE?) is announcing itself as "localhost", I would reject you for that as well. Change this to your FQDN and it should work.

Thanks Rolf.  You are right of course.  0.0.0.0 isn't a valid net IP address and nor is anything else with the first octet as zero.  I made the change you suggested and Allowing 192.168.0.0/24 addresses caused connection failures (because the clients are in the 192.168.17.0/24 range).  When I allowed 192.168.17.0/24 all was well.

Thank you

Gordon

Mail for domain mailboxes should not be treated differently than any other message during the SMTP transaction. In fact it can't - during HELO no RCPT is even known, and a message could have several RCPTs of which not all are destined to a domain mailbox.

It could be that some daemon, for instance GrayWall, intercepts a message before the rule triggers, though.

You can in many cases use the log action (L) to test a transaction rule.

/Rolf 

[quote user="Thomas R. Stephenson"]FWIW my philosophy in running a mail server is to first receive all good mail and second keep out most of the spam.  A 1% false positive rate where you block good mail is not acceptable in my systems.    [/quote]

Mine is similar: I don't accept happily any method that permanently removes legitimate mail from the system.  Spammers have made it easier by using names that actually don't exist, so I have an ever-growing list of names that are flat-out culled 'cause no one ever used 'em and no one ever will.  That, plus the greywall, puts me at something like 2 spam a day, which I can happily tolerate.

This current wave of non-stop spam is annoying, but as long as I don't watch Mercury's SMTP server window my blood pressure's easily controlled.  ;)

Lately all the spam has been in Japanese, with Japanese FROM addresses, which makes me think they're targeting the language based on location (My server's in Japan).  These ones are also re-trying mails denied by the greywall.  Two new behaviours which are interesting to note.

Hello,

I have a problem and do not know what to do about it. I have Mercury running on a W2003 server and Pegasus available for users through WinXP.

I updated this afternoon my mercury version to the latest stable and at first everything seemed ok. I noticed that my daughter got a lot of spam, so i editted again the black list in mercury and then i updated. So far so good but when i told her that i tried to rename her emailadres with a number behind her adres @domain i find myself in error because she did not inform her friends about the change. So i returned her adres back to the original. Everything seemed ok then.

This evening i told her to clean up and let her friends know that i am going to change her emailadres as told earlier. When i used her name in Pegasus i got the message: The user you are attempting to 'become' (marjan) does not exist on this system. So i went to the server and looked, it was gone!!!!!! So, i have extended backup running so i make her emailadres again on Mercury but the system does not comply. As if it is invisible to me and Pegasus but not for Mercury.

Does anybody know what to do?

Please, this is far beyond my comprehension (-:

Thanks in advance

Anne

Edited because i found a workaround: copy user(s) map (the map Pegasus uses to store mail), delete user(s) make new user(s) and set all settings and copy content from copied directorie over the newly created dir.
Check if all settings are correct

You're very welcome to upload the popfile deamon here...

There is a new version of PopFile (1.1.0) in the PopFile web site. The
current version of the PopFile daemon for Mercury (PopFileD v1.22.4) works
with the new PopFile.

You just need to make sure that you re-install PopFileD 1.22.4 AFTER you
have upgraded PopFile to 1.1.0.