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.

i've made two rules:

 1. if size < 10MB than deliver (forward) to recipient

2. if size > 10MB than delete message

 and it works! :)

 thank you for your patience and help.

 

That is an error response from your SMTP smarthost.

Turn on MercC session logging for a bit more detail, it seems to think there are syntax errors in the mails you are sending out.

I suspect your From address: WASH test <michaelbrown......

Should have quotes around the description field at least. The core log should only show the real address <michaelbrown@whatever>.

[quote user="gromit"]oops, sorry, my mistake.  I did not see the reply from Thomas until after I made another post.  Thomas, I've tried what you suggested, but, well, when the head of the company is one of the culprits, well, ahem, it's hard to put it that way. If it just gets automatically cleaned, then they seem to take it better.   Right now they have realized the maintenance does not touch other folders, so they take full advantage of that.  And I'd have to change theri password to get into their mailboxes, something I am not willing to do (nonrepudiation and all).  Thanks for the feedback, though!  

One thing to think about.  The v4.50 Public Beta  comes with a utility called mbxmaint.exe.  If nothing else you can run this on the users mail folders and compress the folders to remove the deleted messages.  Since the folders for all v4.x are the same it can be used with v4.41 as well.

FWIW, if the head of the company is the worst offender why not just advise him that you need to get a bigger hard drive (or RAID array) for the mail server since everyone is saving all of  their mail.  I'd provide a spread sheet showing the drive usage by username as well.   ;-)   I actually did this with one of the K-12 schools I was supporting since the biggest drive space hogs were the Principle and the admin folks. [/quote]

I think I found the problem.  I needed to put in a username and password for outgoing mail since it was moving from Comast to the ISP instead of direct the way it was with the DSL connection before.   That seemed to have fixed the problem and none of the e-mails since have generated an error message.

 

Ron

[quote user="lanwanman"]

Thomas:  Thanks for your reply.  The installation of Mercury server and the

distribution list setup seem fairly straightforward. Only one thing...I'm

running an Exchange server on my network. I have some concerns. I

realize some of my concerns may beyond the scope of this forum. Any

input on the following?

1. What is best practice? Install Mercury server on the Exchange Server or on a separate server?

Depends on a couple of things.  If you have a XP system laying around not doing anything i would use it.  If you can tell Exchange to only use port 25 on one IP inerface and mercury/32 on the other I would run them both on the same system.  It no best practice here, do what you need to in your setup.

2. Will I be able to add my Exchange Server email domain name to Mercury server without any conflicts with Exchange Server?

No, every SMTP host needs it's own domain.  Or course you can use Mercury/32 as the front end to Exchange (handy for filtering, anti-spam, and anti-virus) running on a port other than port 25.  Check the Mercury downloads section for the Petr Jaklin WSMTPEx program. 

3. What smtp server am I using to send out the distribution list? The Exchange Server or one created by Mercury?

Agains depends.  Mercury/32 MercuryE can send direct or using MercuryC via the Exchange (or other SMTP host) as a relay host.  I would perfer to offload the mailing list to MercuryE to keep the load off Exchange.

4. Do I need to be concerned about getting blacklisted? Why or why not?

You are always concerned about blacklisting.  The people getting your mailings, even if they are not on a double authenticated opt-in to the list, can quite easily report your mailing as spam and get the IP address blacklisted. I've not had that happen but then I'm only running reunion type mailing lists.  If you are doing commericial type mailings it's a lot more of a problem.

[/quote]

there is no other way to do that?

It's not a server-side setting, I'm not sure if Pegasus has it.

/Rolf 

[quote user="vmgracia"]

how can I force an account to be used ONLY from imap4 and disallow to be used from POP3?

Actually it's pretty tough to do as long as the POP3 server is running.  If they are on a fixed IP address you can block their access via the POP3 connection control but other than that I cannot see a way to do this.

[/quote]

[quote] We have thousands attempts every day targetting MercuryP/I and MercuryS - they're all blocked automatically by the built in functionality of the modules short term black listing when repeated compliance fails.[/quote]

That is exactly the functionality I wish for, unfortunately there is no Blacklistig just for failed LOGIN attempts.

[quote]However to your fear, you have to enforce a password policy among your users that isn't all that easy to crack.[/quote]

Yep, looks like that is the only of defense right now.

At any rate, thanks to all who answered, your help is much appreciated.

Regards

Ceph

Thanks a lot!

Konrad