Yes Paul, I was referring to the link indicated, however I have managed to resolve the problem. Senility figures into this. [:)] My port redirect was actually working okay. It helps though if the port one is redirecting to is opened to accept the connections. [:D] I opened 2525 in ufw and connects are now getting through to Mercury.

Through all of this though I came across something of interest. The highly recommended procedure for adding rules like this in Debian-based system is to utilize  /etc/init.d/local rather than an /etc/rc.local. Here's a link:

That's the routine I am using .

I also did alterations to the redirect sample line to fit my needs. Because I have several ethernet connections I specified the one I wanted it on. Also, I guess

REDIRECT --to 2525 works but I "think" it actually should be REDIRECT --to-port 2525

Here's what I came up with for myself:

iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 25 -j REDIRECT --to-port 2525

If you are using an IP address in place of a domain name in a mail address you should enclose it in brackets - ] (but many servers won't accept mail addressed like this anyway).

You are using MercuryE end to end delivery module but nobody will be able to help you with a connection error if you hide the real addresses - there can be many reasons why you may have trouble with these deliveries.

[quote user="incose"] Thanks, more details would be great. I have a simple scenario, just 1 domain, but with off-site users that pop their mail from the isp mailbox (the e-mail domain is of course the same as the e-mail domain of the local network).[/quote]

I don't quite follow you with the 'e-mail domain', but here's an example:

If you have a user joe with email address who wants to collect his email from joe70@ispmail.com.  Create an alias (in Configuration / Aliases) with joe@yourdomain.com as the alias and joe70@ispmail.com as the real address. Then any mail for joe will be sent on to his isp mailbox.

(Note that this is just a simple example and doesn't keep any of joe's mail on the Mercury server.)

> So I get this error when trying to send mail in PHP mail(). I checked

all the SMTP options in mercury mail,
> but didn't find any that would

disable the authentication need.

>
> How can I remove authentication for SMTP in Mercury Mail?

Configuration | MercuryS | Connection control will allow you to turn off the authentication but why not just turn on the authentication in you PHP mail()?

Thomas:

 Thanks for your quick response.  I think I figured out the problem on my own.  By examining CC and BCC as well as To and From, the POP3 Client tried to send the emails with CC's to other company users to the recipient as well as to all of the folks on the CC list, with the result that some users got the same message as many as six times.  I removed the CC and BCC from the Headers box and now have POP3 Client examining only To and From.  So far, no problems.  

In our setup, we have the POP3 Client picking up all incoming email from one common domain mailbox, the redirecting it through the Mercury Core Process and to the SMTP Client (relay version) to send it to the personal email accounts of the various users.

If I see any strange duplicates popping up, I'll get some more information and post it here.

Many thanks!

Ron

have migrated to a linux vServer now (yesterday) (took me some hours, it is not a "no-brainer" like mercury, and costs me 4$ a month)... BUT

it is REALY amazing fast...

have NO problems with android/thunderbird ...

(had to delete 1000s of emails in sent folder, because of bug in mercury..)

the most amazing Thing: 

when marking a message as read in thunderbird, it gets marked read on the phone in REALTIME (2 seconds!) (and vice versa )

i am using ubuntu->postfix(with maildir)->dovecot->roundcube...

1:1 copied all emails with "imapsync"..

Receiving a message from an email client running on the server should be lightning fast. Delivery via MercuryE to some server on the Internet will of course depend on a number of factors, but should in general be very quick as well.

Create session logs from MercuryS and/or MercuryE to find out exactly where the delay happens. Possible reasons for delays could be a misbehaving sending program, or some program interfering with Mercury's access to files or SMTP connections (such as for instance an antivirus program or some spam filter).

/Rolf 

I have had some success.

What are you trying to achieve?

Chuck

Thank you, Paul, for pointing out the existence of the logical AND in the interface, and thank you, Gordon, for finding it and posting the location. I'd searched the interface for a logical AND but failed to find it - I think I must have assumed that the actions listed under "then do this" would all take place at the end of processing.

I've input my rule using the interface and it works. Interestingly, the syntax for the AND is different from that in content control. Also, my manually input incorrectly formatted rule has disappeared, Mercury presumably having cleaning it up.

Chris

> I added a second MX record to my domain, pointing to a different server. The records point to 'mydomain.com' with priority 1 and to
> 'secondary.com' with priority 10. I was assuming that email would be delivered to 'secondary.com' only if 'mydomain.com' was not available.

> However, I am seeing some email delivered to 'secondary.com' even though mydomain.com was up and receiving email at the time. Some of
> this email comes from legitimate bulk mailers (e.g a newsletter from an association I belong to). The rest is spam. I've even seen one or
> two delivered to primary AND secondary.
>
> I'm curious whether the mailers sending to the secondary are broken, or whether I misunderstood the semantics of the priority in the MX
> record.

You understand the rules for a MX host, however many spammers automatically connect to the highest numbered MX host to bypass the anti-spam settings of the primary host.  In addition, even if your primary is up there may be something you're are doing to reject and then many host just go to the next higher host even when they get a 500 series fatal error message.

Personally I use the following MX settings where the highest host points back to the primary to try and bypass some of this.  ;-)

  tstephenson.com, MX, 10, mail.tstephenson.com
  tstephenson.com, MX, 20, mailrelay.bayarea.net
  tstephenson.com, MX, 30, mail.tstephenson.com
 

> Is it possible to force a Reply-To header on a mailing list?  I'm seeing that some clients default replys to the list, while others default to the sender.

Shure? If "Reply to list" isn't set, answer should be send to FROM. SENDER is the header for the mailadress of sending instance - most times the adress of the mailserver. It's for automated routines ... not for mailclients.

> I see there is an option to "force replies to go to the list"

Forces mailserver setting a (new) REPLY-TO to mailinglist ...

> but what about forcing them to the sender?

To your mailserver?

A mailclient should look for REPLY-TO and - if not present - take FROM for replying. But - as with Pegasus - there is no problem telling the mailclient to ignore REPLY-TO ...

I never had problems with that feature on restricted lists. Are there replies not sent to FROM or in case of error to mailadress defined for ERRORS-TO?

Hope this helps

    Olaf

Many thanks. Didn't realise there was a dedicated Pegasus forum.

Thanks again for all the help. After switching to Mercury E I have had no issues.

Thanks

Ray Heinz 

I know I was getting emails through using Mercury before my W7 re-install. I know I was doing substantial 'testing' of Mercury's functions and parameters without it ever crashing. Now I'm NOT having that success at all.

I apologize I think I have shown bad attitude in coming in to this wanting to prove it was some sort of a uninstall/reinstall application problem. 

Thomas is correct. I am barred from the SMTP "E" system. I must have been using SMTP "C" when I was having successes. 

I have switched to SMTP C. The crashes are back. I start Merc the first time and can go through everything. I send my email. It crashes. I restart, it crashes. I clear the Queue and can sucessfully restart I can then go through it (until I try to send another email). The crashes are too fast to read the messages in the consoles. After it all: 1) there are a few queue entries for the one email, 2) no mercury C logging entries,

3) 1 mercury C session entry  ...

22:18:33.843: --- Sat Jan 22 22:18:33 2011 ---
22:18:33.843: Connect to '(null)', timeout 30.
22:22:51.385: --- Sat Jan 22 22:22:51 2011 ---
22:22:51.385: Connect to '(null)', timeout 30.
22:24:50.211: --- Sat Jan 22 22:24:50 2011 ---
22:24:50.211: Connect to '(null)', timeout 30.

It certainly crashed in less than 30 seconds!

Yes, there are STRANGE things going on with my ports that I am looking into more before I conclude anything, but hope someone can reason the problem from the only messages I can find.

> From this posting, I have verified that the dm= entry is indeed processed prior to the mailing list entry.  Frankly, this is a bug
> IMHO.

The mail for a mailing list uses the list name and the domain as listed in Configuration | Mercury core | "Internet name for this system" and that should never be a domain mail box.  To address a mailing list is will be <listname.from lists.mer>@<internet.name.for.this.system>

I'm not sure what you are doing here with the dummy domain to get access to the lists.

Thanks again Rolf :)

Posted to the list as well - added info here for those that are forum centric.

Finally got it to behave with version 4.62 and an outgoing rule filter. I

do use the interface to create my rules and somewhat condensed what each

entry does so that it didn't line wrap terribly in my post(s).

I found my problem. It turns out that 'someone' changed my firewall settings on me (after 'someone' disabled the firewall I was soon to replace, anyway) and there was something that Mercury didn't like about Windows 7 firewall 'public' settings, for which. I apologize, I have investigated no further than to turn that off (for now anyway).

I may be following your recommendations as through it all I'm now getting 'core' errors on my admin mail file. But first I gotta get to why 'someone' now keeps turning that firewall setting back on on me (grrrrrrrrrrr). Thank you, Rolf!

After Microsofts patch tuesday (9 updates), the mail is running OK.