I was having a tough time with this type problem myself. My setup is as follows: Mercury/32 v4.52, SquirrelMail v1.5.1 (1.4.15 worked ok too) on IIS 5.0 [SquirrelMail is separate from my Mercury/32 server], PHP 4.3.4 and NetWare OES 6.5.6 storing messages. SquirrelMail is run from a virtualized directory of C:\MAIL and PHP is located in C:\PHP.

I found out the hard way that the PHP.INI must have fastcgi.impersonate = 1 and that the redirect.php from v1.4.15 of SquirrelMail make this work well. I even have the address_add plugin working (not under v1.4.15, though). I highly recommend using the autosubscribe and folder_sync plugins also. The documentation for this is very poor and that made for lots of trial and error to get this going...

HTH 

[quote user="Anthonyd"]

Hi, Can anyone tell me if there is a simple way to send a message to all my users in Mercury?

[/quote]

 A list of valid recipients can be obtained by simply listing the mail directories in the directory where they are kept.  From a command prompt you could, for instance, "cd\mercury\mail && dir/b/ad >rcptlist.txt".  Now, rcptlist.txt is a distribution list you can tell Pegasus Mail to mail to.

Cheers,

Sabahattin

[quote user="TonyRad"]It looks like after I closed out the problem accounts a bulk of the problems stopped. Now I have just a few that don't seem to want to send, I'm not seeing any error messages or anything though, I'm not sure what I should do about them?[/quote]  I've been looking at this one for some time now and I cannot figure out anything that could be causing the problem.  Does this problem still exist?

Thanks dilberts_left_nut.

I see what you mean. I have tried setting an outgoing rule to look for the offending text in the header and replace it but to no avail.

I should change the computer's name anyway so I guess I'll end up going down that route.

Cheers,

Reece

[quote user="jbrowne"]

Two questions regarding delivery confirmation:

 a)  Would allowing delivery confirmations to be returned to senders, am I saying 'yes' to receiving more spam?

[/quote]

No, but it probably is saying "Yes!" to the generation of more spam; unfortunately, though your autoresponder may be harmless, some people will find it annoying if they receive it unsolicited and will accordingly often report it as spam.  I should think carefully about whether or not you really need an autoresponder.  See this:

http://www.spamcop.net/fom-serve/cache/329.html

Mail is dead easy to forge.  A spammer just includes your autoresponder in his list and forges the sender to be some unfortunate somewhere and your helpful autoresponder will be sent to someone with no connection to your company.

The default (I.E. usual) behaviour of an RFC821-compliant mailer is only to report delivery failures.  If you don't accept mail for which you can't then accept responsibility (this is configurable in Mercury), you should have no reason for generating mail to innocent people.  Also, enabling Delivery Confirmation by itself isn't enough to cause a receipt to be generated; Mercury looks for a header to be present and mails the confirmation to the address in that header.  There is a more standard way to change conventional SMTP behaviour using the DSN extension and format - see RFC 891.  Mercury doesn't support that.  Delivery confirmation will only be generated on request, in any event.  So even if enabled, spammers have to knowingly abuse the feature, and most don't - yet.  I don't advise you to go ahead and provide an easy way for spammers to make you generate backscatter.

[quote user="jbrowne"]

b)  How possible would it be to use filters, daemons, to have automatic delivery confirmations sent back to people that email my company (even when they do not use the delivery confirmation option in their email client)?

And maybe have like an opt-in opt-out for those automatic delivery confirmations? (list of sender's email addresses that request them).

[/quote]

Yes, it should all be entirely possible using just rules and distribution lists.

Cheers,

Sabahattin

is posted here:

No, not possible.  Most changes are now written to mercury.ini immediately though.

Hi

Solved the problem, Mcafee was seeing Mercury as a mass mailer and had the port blocked.

Thanks for you help.

Regards

Simon 

The got MG* is an inbound job from MercuryS or MercuryD.  Could be a bounce message, could be spam but if it's not to a local user then it's going to be bounced.  Need to see the rest of those lines.

Maybe nothing, the host might be down.  Try to ping the host and then try telneting into ports 25 and 110.  If these are successful then checkout the firewall setting to ensure you are not blocking WinPMail.  I generally try running a session log when this happens to see exactly what is going on.

Why not open port 110 (or a non-standard port like 8110) to your mail server so your offsite users can get the mail directly from your server?

If you don't have a static IP or domain name you could set up a 'dynamic dns' one.

If you are doing this you could also open an SMTP port so all the mail goes out through your server as well. (would recommend a non-standard port if you are not wanting to receive mail by SMTP) 

Another option is to set up a forward or alias for these users, but it would have to point to a non-local address.

I will complain :-)

Well.

I have the same problem here. From the moment I first time installed Mercury, year and so.

And it is a WONDERFUL PRODUCT but this little annoyance is just ... annoying :-)

When I start Mercury it fetches my emails via POP3 from outside mail server and delivers them locally to be read by IMAP client.

Of

FIRST fetch, no matter how many emails fetches - app. 1/4 messages get

stucked by "Transient error - job deffered for later processing".

Others are delivered but this 1/4 stays in "Pending" state. After some

time(?) they get delivered to. Don't know about this "time" parameter

but I would say it is something about 20 mins or so.

At that time many files in QUEUE have  this "File rename failure for xxxxxx" message.

Now, I have NO AV program, NO any other  program that would access files and interfere with mercury. No NOTHING.

Frankly, I would plainly say there is a bug somewhere so please fix it and make this great software even better.

Your session log should show something like:

[quote]

FOR CRAM-MD5

13:48:28.243: >> EHLO [192.168.0.3]<cr><lf>
13:48:28.246: << 250-mail.mydomain Hello [192.168.0.3]; ESMTPs are:<cr><lf>250-TIME<cr><lf>
13:48:28.249: << 250-AUTH CRAM-MD5 LOGIN<cr><lf>
13:48:28.251: << 250-AUTH=LOGIN<cr><lf>
13:48:28.253: << 250 HELP<cr><lf>
13:48:28.265: >> AUTH CRAM-MD5<cr><lf>
13:48:28.268: << 334 -munged challenge hash-<cr><lf>
13:48:28.282: >> -munged response hash-<cr><lf>      << Base64 decode this line to get the username + morehash
13:48:28.282: << 235 Authentication successful.<cr><lf>
13:48:28.295: >> MAIL FROM:<user@mydomain><cr><lf>

FOR FOR AUTH=LOGIN

14:08:19.268: >> AUTH LOGIN<cr><lf>
14:08:19.275: << 334 VXNlcm5hbWU6<cr><lf>
14:08:19.369: >> -munged base64 username<cr><lf>
14:08:19.369: << 334 UGFzc3dvcmQ6<cr><lf>
14:08:20.461: >> munged base64 password<cr><lf>
14:08:20.461: << 235 Authentication successful.<cr><lf>

 [/quote]

If you get no AUTH lines in your session log, then Thomas is right, and you are a (partially) open relay  [:O]

[quote user="Judah Davis"]Can Pegasus Mail operate as an IMAP client?  We have only used it as a POP3 client.[/quote]

Yes, it's had IMAP4 capability for some time now.  Use Tools | IMAP profiles to setup the IMAP4 accounts. 

The outgoing e-mail still goes to Mercury, although the definition in Pegasus correctly specifies my ISP's mail server. Even disabling MercuryC doesn't address this - e-mail still goes to Mercury.

I have checked the "Use in preference to LAN mailer" box in Pegasus, and that seems to have done the trick.

Thanks for your help, Rolf.

cheers,

david

I have in the past and am currently now running two instances of Mercury/32 looking at the same mail store delivering the mail.  Generally there is no problem at all and we are processing about 500 messages a day.  Just make sure the only thing common to the two instances are the same mail store.  The must have a completely different directory structure except for the mail directories.

 Edit:  FWIW, multiple instances of Mercury/32 on the same system is not a problem.  You'll have to have separate IP addresses for each version to do SMTP delivery on port 25.

hm the checkboxes was already not ticked but i have enable the copy-to postmaster function if there are errors.

i try to check it again if i get the loop-discarded-info again

Thomas & Dilbert,

Thanks for taking the time to correct my naivety in this matter. I'll take a look at the POP3 connectors, which is where Thomas directed me to in the first place.

Regards,
Richard

> Hi again
>
> Yes, 110.66.159.212.is the IP of our mail server and
> mail.mischiefkids.co.uk is our own domain name.
> I did set the controls to disallow everything as you said Thomas,
> and above the disallow I put the mailfoundry range of addresses.
> As some valid mail could not then get through (e.g. coming from
> Yahoo) I had to remove the disallow.

Ok, now that we have the info I think we can see the problem.  Your domain is really
mischiefkids.co.uk and this mail is being routed via the mailfoundry address.  The name
mail.mischiefkids.co.uk is the name assigned to your mail server.  If you sent mail from Yahoo
to user@mischiefkids.co.uk it should have gone through properly.  People should not be
sending to user@mail.mischiefkids.co.uk unless they are spammers and you want them
blocked.  Mail from Yahoo to your domain addressed to user@mischiefkids.co.uk should be
sent via the mailfoundry hosts.  

Answer Section:
    mischiefkids.co.uk, A, 89.145.78.228
    mischiefkids.co.uk, MX, 10, mx1.mailfoundry.com
    mischiefkids.co.uk, MX, 10, mx2.mailfoundry.com

Answer Section:
    mx1.mailfoundry.com, A, 66.18.18.112

Answer Section:
    mx2.mailfoundry.com, A, 66.18.18.113

The domain mail.mischiefkids.co.uk though has no MX records at all.  Any mail to
user@mail.mischiefkids.co.uk is going direct to the server.  

Answer Section:
    mail.mischiefkids.co.uk, A, 212.159.66.110

You are trying to block people from sending mail direct to the server and this address should
not be accepting mail from anything but the mailfoundry MX hosts.


>
> It would seem that Dilbert is correct (thanks for that Dilbert) and
> I will just have to be patient and keep trying the disallow settings
> every few weeks.

Not really, you need to get a tool to check the DNS records for your domain every once in a
while to verify what is being propagated to the world. The site CheckDNS is a good place to
start.  FWIW, I use the free tool Cyberkit to do this sort of thing.

> Thank you for your input and confirming that my DNS settings are
> correct.
> Lynn

Do a 'file compare' on your two mercury folders and play 'spot the difference' [:D]