4.01b

 I managed to get it working, but it's a real kludge.

• I deleted myself, user "Pete" from Mercury
  
• I created a new user called mailbox which I now send with a reply-to of "pete@"
• I created a mailing list "Pete"
• I created a mailing list "Tmob" for my T-Mobile device with no welcome nor farewell file and made the mobile device address a moderator and active subscriber
  
• I created a mailing list "Cing" for my Cingular device with no welcome nor farewell file and made the mobile device address a moderator and active subscriber
• I subscribed mailbox, tmob, and cing to Pete

I can now do what I wanted. EMailing maiser@mydomain

add tmob any@email blah
mset any@email tmob nomail

will forward that address to the device, and

remove tmob any@email

will stop forwarding. (I replace "tmob" with "cing" to do the same from my cingular device). But like I said, it's kludgy.

We use port 110 on the local network and a random high port externally.

The internet gateway 'port forwards' this high external port to port 110 on the mail server so merc only needs to use one listening port. 

Should make no difference where the mail comes from in MercuryS. Or do you mean POP3 download using MercuryD? Anyway, temporarily switch on session logging for the module in question to see all details of the transaction. (And remember to switch it off, it wastes a lot of disk space otherwise.)

/Rolf 

[quote user="Slab"]

I just had a problem with the outbound mail queue freezing.  What happened is a spam message came in with an invalid email address going to an invalid email address ( to invalid2@mydomain.com)  What happens is that a return notice keeps bouncing in the queue trying to send the non delivery receipt to an email address that doesn't exist internally.  Is there anyway to prevent this from happening.  I've had messages get stuck in the queue before, but this is the first time it actually hung processing.

Almost forgot.  It is running on a Win2k server.

[/quote]

 

What I do is turn all mail being received for invalid local users in MercuryS.  If mail is received via MercuryD leave the local user blank so that Mercury core delivers the mail and mail for all invalid users goes to the default user without a bounce.  With this setup MercuryS rejects the message before it's received so no bounce message is generated.  With mail received via MercuryD the default user processes it as desired.

 

 

The problem is less something specific to Mercury than a widespread problem in the way SSL is implemented generally. There are many different libraries and versions of libraries for doing SSL and not all of them interpret the specifications in the same way.

Now, with MercuryP, MercuryI, MercuryC and MercuryD, it's not too much of an issue, because they're only talking to a fairly limited range of implementations, so if there's a problem, it will become obvious at an early stage. Enabling SSL in MercuryS, though, exposes you to every implementation in Christendom, with all their vagaries and differences. For this reason, I generally do not recommend enabling SSL in the SMTP server - and will not be recommending it until the industry settles down considerably in this area.

Cheers!

-- David --

It's all sorted [:D]

Turns out that it was just the password stuff in Mercury that had become corrupted - new password setting - job done.

Can't believe I have spent 5 days driving myself (and everyone else) mad over this.

Thanks again and hopefully back to another happy and trouble free five years of Mercury & Pegasus.
Oh! and once you sort out the licensing stuff - 5 mailboxes here please

Lynn
 

@

 

You posts and your sites deliver a quite considerable hype on something that's been around 3+ years now.

 

Question: what makes your "Hermes" better than the other 150+ plain-whitepaper Greylisting implementations available everywhere? 

THAT would be a really useful information to all of us...

 

Thank you!

 

After setting up ClamWall I just fount three files left, and they look to be left while the server was starting, and therefore ClamWall still was loading. It looks like to be some kind of time-out, then.

ClamWall can quarantine infected messages to a file system folder, what it can do is to quarantine them to a mailbox, and to check a file folder remotely is more cumbersome than checking a mailbox - and requires to have the right TCP ports open on both ends.

Thank you for your help.

 

[quote user="OldManRiver"]

1. Move the Email to the appropriate mailbox (the rules tool does not always do this),

[/quote]

In that case you need to rework the rule. While there is a to-do list for Mercury, there aren't any known problems with the rule engine - it's been around for well over a decade now and is quite proven. If a rule isn't working the way you expect, then you need to reconsider the expression or terms you're using to trigger it.

As for the rest... You can proceed in one of two ways:

1. You could create a rule that executes external program that does the processing you need.
2. You could create a Mercury policy that passes the message off to an external program.

Extracting the attachment to the directory is probably possible using a rule (depends on whether or not the excel attachment explicitly includes a recognizable file extension, but it almost certainly will). Printing is a little more complicated - you *might* be able to do this from a "Run a prorgam" rule, but that depends on your system and the applications you have available. The policy or external program approach would give you the greatest flexibility in how you proceed.

Cheers!

-- David --

[quote user="Paul"]

This post in brief: To have the MercuryP POP3 Server give you your emails in the order they were received (FIFO) you must use FAT32. If you use NTFS they will be mixed up.

[/quote]

I just want to make it clear that you mustn't rely on the order of messages provided by a POP3 server  - ANY POP3 server, not just Mercury. The RFCs for the protocol make no mention of ordering, which means that there is no standard interpretation. If Mercury presents messages in a particular order because of a foible of the underlying file system, then that is an accident, not a matter of design.

Now, with the preceding paragraph in mind, it *would* be possible to add a degree of sorting to MercuryP - quite easy, in fact... But it would always have to be a specifically settable option. I'll take a look at the code and see just what might be practical.

Cheers!

-- David --

 

Ben, most likely you're suffering a reverse lookup problem. To my knowledge, both Google and Microsoft require valid reverse lookups as to accept inbound e-mails. As stated above, youre HELO or EHLO needs to match your actual sending IP that in turn resolves when doing a reverse lookup. Check up on your own host and mailer, to see how it complies by using the DNS-Report at: .

Also, you say you don't worry too much about inbound, - you should! If your mailserver is reported as an open relay, you will be treated as a spammer. Now, since you most likely only will allow SMTP connections from the very same machine, insert Allow 127.0.0.1 into connection control options of MercuryS module. Since we serve many domains, we nearly only allow authenticated SMTP connections to relay, meaning to check the last two boxes on Connection Control in MercuryS. Besides the authenticated, some internal servers are allowed within connection Control, all else is thus only allowed to connect with inbound email to local addresses.

[quote user="bfluet"]Paul is dead on.  My ISP is Deltacom and it's their server address that is being written to the From header.[/quote]

What this indicates is that the message is going out without an FQDN (fully-qualified domain name) in the From: field. So, say the user's name is "Bill", the from: field is going out as "From: Bill" instead of "From: Bill@domain.com". The ISP will be running Sendmail, which normalizes messages that aren't conformant in this way (although what it does is not actually very useful).

For the life of me, I can't remember if this issue was ever resolved during the v4.5 development process or not - I certainly remember looking into it, but I can't remember what the outcome was. If I can get a chance this afternoon, I'll take another look at it, but if you find it still happens after v4.5 gets released, raise the issue here again and I'll look into it in more depth.

Cheers!

-- David --

[quote user="SteveYates"] When delivering mail to a mailing list, Mercury resolves the MXs first and then tries to deliver messages destined for the same MX together in one SMTP session instead of separately.

 <snip>

T 20070509 092400 4641d236 Established ESMTP connection to 64.18.7.10
T 20070509 092400 4641d236 MAIL FROM:<Mary@example.org>
T 20070509 092400 4641d236 250 Ok
T 20070509 092400 4641d236 RCPT TO:<user@example.com>
T 20070509 092401 4641d236 250 Ok
T 20070509 092401 4641d236 RCPT TO:<user2@example.net>
W 20070509 092401 4641d236 451 Recipients not all at same mail host - psmtp[/quote]

Why doesn't postini allow this? And as a consequence why have the mailadmin set the same mx for both domains, if postini doesn't allow this behaviour?

Have you asked the postmaster at 64.18.7.10 about this issue?

I don't think you need to install a email server for this, assuming your isp has a smtp-server  you can set smtp = <isp-smtp-server> in php.ini.

http://uk.php.net/mail

 

I still use MercuryX to schedule collection of POP3 mail and sending SMTP mail via our ISP. We now have broadband, but still use a dial-up account when the broadband service is down. I run a batch file before starting and another batch file after stopping.

The 1st batch file contains the following line:
start "RASdial connect" /min /wait rasdial "<account-name>" <username> <password>

The 2nd batch file contains the following line:
start "RASdial disconnect" /min /wait rasdial "<account-name>" /disconnect

I've never experienced any problems with this method (OS: WinNT and Win2K).

I hope this is useful to you. Good Luck.

Stephen.

[quote user="yravi"] Our institution has 2 mail servers on different domains maintained by 2 ISP's across the globe.[/quote]

Email is routed based on mx-pointers within the dns. For your two domains, the mx-pointers either go to you ISP or to your XP machine.

If the mx-pointers point to your XP-machine all e-mails will be delivered to it, and received by using MercuryS, SMTP Server. 

If they point to your ISP, you can collect all the mail by the XP box, so that your users later can retrieve the emails. The module to use to download mail from your ISPs is MercuryD.

[quote user="yravi"]     vbsa.com
    vbsb.com[/quote]

Configure these two domains in "Configuration" | "Mercury Core Module Configuration" tab "Local domains"

[quote user="yravi"] we have 10 to 15 mail-id on each mail server. I want to configure my Windows XP box which is connected to Broad Band Internet connection and have installed mercury/32 on it to distribute mails to the clients on outlook express in the LAN. Bascially I want my XP system to work as a mails hub.

ex:
  
   info@vbsb.com
   hodphysics@vbsa.com

[/quote]

Under "Configuration" | "Manage Local users", you add mailboxes. A mailbox works like your mailbox by the road, it can receive mail addressed to many nick-names as long as the delivery address is correct. A delivery address is set up using aliases.

Under "Configurarion" | "Aliases", you tell that info@vbsa.com should go to the "real address" which is the local mailbox, you can also add any other alias to be delivered to the same mailbox (ie "Real Address".

Hope this helps

[quote user="Methuselah"]
Local Users:
 Username=TechnoMail, Personal Name = Robin Martin

Core/Local Domain:
  LocalHost = YMCSERV, Internet name = technolib.coza

 Aliases:
  Alias=robin@technolib.coza, Real address=TechnoMail

THIS WORKS - via Mercury spooler only . . .  at last !![/quote]

My goodness, you're really good at trial and error. Now here is an explanation:
Real Address within the Alias configuration, is either

Configuration interfaces is hard to do that are so intuitive that someone with limited knowledge can set this up. As programmers it is also very hard to imagine, how someone not involved in the lingo reads the interfaces.
Nonetheless, you DID IT! Congratulations.

Just to clarify:

• MercuryS: SMTP Server module that receives incoming SMTP email from SMTP clients and from other SMTP servers.
• MercuryC or MercuryE: SMTP Client module that sends outgoing SMTP email to other SMTP servers; MercuryC is a relay client that simply relays all outgoing mail to a specified SMTP server whereas MercuryE is an End-to-end delivery client that can do domain name resolution in order to contact the recipient's SMTP mail server and deliver the SMTP email message directly.
• MercuryP: POP3 Server module provides new emails to POP3 clients
• MercuryD: POP3 Client module downloads new emails from other POP3 hosts on behalf of your users

I recommend that you keep the "do not permit SMTP relaying of non-local mail" option enabled at all times.  Otherwise, your Mercury server will become known as an "open relay", which is a bad thing and which will get your Mercury server's IP address added to various blacklists.  Instead, I recommend adding your local subnet(s) to MercuryS's connection control's Allow column and optionally enabling the "strict relaying" option.  If you have any remote users that use public IP addresses outside of your control, then see about using SMTP authentication in Outlook when relaying email through Mercury.

 

Welcome to the Community Support forum for the Mercury Mail Transport System.

What this forum IS: 

a place where you can ask questions and give answers, where Mercury

users can share their expertise and experience with each other for

the benefit of all.

What this forum IS NOT:

an official technical support forum. Whilst I and my test teams will

participate here as much as time permits, the fact that you post a

question does not create any formal obligation on us to answer it. We

will do our best to assist you as time and circumstance permits.

Rules for using this forum: This forum is provided as a community service: as such, certain rules apply.

• No

  flames, outbursts, bad manners, slurs, abuse or rudeness. Discourteous

  behaviour will not be tolerated. Forum moderators will delete posts

  that breach this rule without notice or apology. Don't get me wrong:

  you're welcome to complain here - but if you do so, do it courteously

  and respectfully and we'll all get along fine.
  

• No spam or advertising. Don't post irrelevant messages or advertise products unless they are directly relevant to Mercury.
• No large attachments, please.
• No wishlists please - not because we don't want them, but because there is another forum specifically intended for them.
  
• No WareZ, no links to illegal download sites, no porn, no material that breaches copyright.
  

To participate in this forum, you must be a registered user of the site.

These rules notwithstanding, this forum is provided so that we can all help each other. Enjoy!

-- David Harris --

I know of three occasions where this happens:

1. When two Mercury/32 processes are running simultaneously (by mistake) both are polling the same queue, leading to several identical mail being delivered.
2. When using MercuryD (POP3 client) a mail might be too big, or a TCP/IP error might occur during the transaction. Then MercuryD won't delete the mail from the POP3 host, and it gets redownloaded at the next try. Try setting the timeout to a larger number, and increase the time between POP3 connections as needed.
   
3. Some double-mail IMAP errors with Thunderbird can be solved by setting mail.server.serverX.max_cached_connections to 1 (where X is the number of the associated account, typically 2) in the Thunderbird configuration editor.