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

Thank you for this explenation. I did as you said, removed the domain mailbox (over the weekend we were flooded with more than 3000 mails). Now the message "job killed by daemon" does no longer appear (even if spamhalter is active)!! It works now as I expected to do. Of course I have now 20-30 delivery failure messages in the postmaster box, but most of spam rubbish is managed away.

Thank you all for your support.

Chris

Thanks, Thomas

Your suggestion is a good one, but as we all know, getting computer users to follow IT procedures is difficult unless you are stood over them. I automate procedures as much as possible in order to make computer usage here easier for everyone. I am looking for something that can be automated and which takes this out of their hands. I would really like to instigate a numbering policy which is consistent across the organisation and which cannot be tampered with by the Pegasus Mail users.

Thinking about it, modifying the subject line would create an impossible situation if many messages were traded back and forth. Appending a descriptive footer would be a better idea, otherwise you could end with incredibly long subject lines.

[quote user="mike.clarke"]

Hi

(This is most likely answered somewhere but I can't find it, I've looked)
I've created a domain mailbox and all the mail that gets send to goes to the managing mailbox.  Great!

But now I need an exception to that rule.
Ideally, I want anything that isn't a local user to go to the managing mailbox, and anything that matches a local user so go to the user.

For example

Say I have two users and a domain of mydomain.com
admin
mclarke

admin is the DM

I want:
blahblahblah@thedomain.com to go to admin
to
mclarke@thedomain.com to mclarke

With what I got, they both go to admin

With a domain mailbox every message to that domain goes into the mailbox unless an earlier action causes the message to be delivered to a user. 

I would create a second domain entry called local.thedomain.com and then alias all of the real users to this domain.  That is, you would alias mclarke@thedomain.com to mclarke@local.thedomain.com so this mail did not go to the domain mailbox.

 Please help

[/quote]

[quote user="airyt"] We are getting lots of spam sent "from" ourselves. And no, we cannot filter on IP address since lots of outgoing mail comes from a variety of machines (hence the authentication).

We have clients who have asked about accessing their Mercury email

account through a web-based interface.  Does the Mercury Mail server

have such an option?  Is there a 3rd Party add-on for the Mercury Mail

server that would allow web-based access to email accounts?

If you have the Mercury/32 IMAP4 interface running the easiest way to do this is via one of the web interfaces like This will allow you to connect from most any location using a web browser.  There are other packages like SquirrelMail, MailBee and Horde and work with your webserver and PHP to allow this sort of option as well.  I personally use SquirrelMail to do this but that's the one I found easiest to get running and it works for us.    There are a couple of commercial standalone webmail packages others use.

The reason is sounds technical is probably that it is rather technical... ;)

It's perhaps best to take it step by step.

Transferring email on the Internet requires port 25. So the first thing to do is to make sure that the device you use to connect to the Internet (DSL modem, router or whatever) has port 25 open, and that any incoming traffic on port 25 is redirected from there to port 25 on the server running Mercury. Make sure there is no firewall program on the Mercury server that blocks port 25.

To send an email you set the SMTP server in your email program to the IP address of the Mercury server. If you run the email client on the same computer as Mercury you should set it to localhost or 127.0.0.1 (which is the same thing). Your email is then received by the SMTP server module in Mercury, and sent to non-local recipients via the SMTP client module (either MercuryE or MercuryC).

To receive an email from someone via the Internet you need to make the public IP address for the mail server handling your domain known to the world. To do this you add a MX record to the DNS information for your domain, containing the hostname of the server. This could be mail.myownserver.info. You will then need an additional A record that gives the IP address for that hostname (which you have, IP is 76.125.92.139).

The MX records for myownserver.info now point to mail6.zoneedit.com and mail7.zoneedit.com, which presumably is not what you want, so you need to change that.

I'm not able to connect to port 25 on 76.125.92.139 at present, so that's another thing you need to check on.

/Rolf
 

 

 

 

 

Now I want to restore the *.TMP files into the SCRATCH folder because

there are also some legitimate mails between the garbage mails. But

Mercury does not care about the *.TMP files and they are still in the

SCRATCH folder. Restarting Mercury did not help. I tried it also only

with just a few mails - no change. Any suggestions?

I assume that you are receiving the mail via MercuryD and these temp files in the SCRATCH directory were created by the program when the mail was downloaded via MercuryD.  This is not always true since there can be other TMP files in the SCRATCH directory.  I also assume that these are RFC 2822 message files.  If so then you can convert them to 101 files and put them into the queue by adding the following lines to the top of the good messages and save them to the queue.

$$ <MAIL FROM Address>
<RCPT TO address>
<blank line. 

The "FOR" designation in trace fields records the recipients for which an SMTP mailer accepted responsibility.  It's rarely used, often not provided, is optional according to spec, and is in any case only permitted to hold one forward-path (multiple forward-paths long deprecated for security reasons).  The FOR clause doesn't record the mailbox to which the mail was delivered - that will be handled by a Mail Delivery Agent and isn't the responsibility of the MTA since it has no function to SMTP mail delivery (Mercury uses a different X-line for this).

 

Cheers,

Sabahattin

 

  

  

[quote user="Thierry"]

Hello,I've installed and configured Mercury.But I cannot send Emails from local addresses such as ict@sfar.local to titi@yahoo.com for estence. What could be the problem with MercuryC?

Evry thing seems to be Ok but I'm getting the following error: 30 Dec 08 09:17, Servicing job MO000006... 550-Verification failed for <ict></ict>

Can anybody help me pls?

Thanks.@sfar.local>

The domain sfar.local is invalid and the receiving system is rejecting for that reason. Change the domain of the sender to a real domain and this will work.

[/quote]