The bug in TRANSFLTR.MER is still here in Sept. 2014.

I try

to run webmail Roundcube as a client (SMTP, IMAP) of Mercury, on the

same machine as Mercury: so the connections of Roundcube come from

127.0.0.1. The filter described above, in TRANSFLTR.MER, blocked

Roundcube from talking with MercuryS, so I simply removed it and the

problem was gone.

Thanks, Thomas. After experimenting with a mailing list it's not going to do what I would like, so I'll stick with forwarding and the SPF users will have to remember it doesn't work for them. 

SPF seems fundamentally flawed in matching the original sender's address with the latest server to handle it, which breaks forwarding. I could see the point of matching the original sender with the original server but I suspect it would be more complex to implement.

> Thank you for your large effort in investigating my problem.
>
> I have no idea about your low level tcp-ip-solution.
> I access the mail directly on the computer where mercury sits (XP Home SP2)!
> I use Imap just to access the mail sometimes on a laptop, normally I work directly on the mail server.
>
> The next thing what I do not understand: If I move the mail to another
> Imap-Folder, I can watch the jpg with no problem!

This is what I find strange.  I can view these message attachments you forwarded to me without problems with WinPMail, OE, Outlook and Eudora via IMAP4 but I cannot do this with Thunderbird.  WinPMail in direct access can view the attachments also without problems.  Apparently there is something about this message that is causing a problem with Thunderbird.

All the clients, even Thunderbird, can view the attachments in the message you sent me via the ZIP file.

>
> Maybe I will compare the Imap-Log-files for this behaviour and tell you some results.

Not sure this will help at all since all of the other clients do not have a problem viewing this message via IMAP4.

>
> Best regards again, Walter

If the installation is correct ClamD and FreshClam should be started once (with Mercury), not for every message. FreshClam will then get new virus definitions regularly.

Try updating to the current version of ClamAV (http://hideout.ath.cx/clamav/), and verify that you have the right paths in conf files and in ClamWall.

/Rolf 

Thanks David.
The email does eventually go.. But normally it takes 3 or 4 retries.

A couple have gone out first time this morning.. !! Maybe they've sorted it ?

 Thanks again.

The Netware server NLM version doesn't, no.

But Mercury/32 running on a windows PC with the Netware Client works perfectly, you can even just use Mercury/32 for IMAP while still using the NLM version for everything else such as mail delivery, this was exactly how we were running things up till about a month ago.

David 

If you set up Spamhalter (or Popfile) you will be able to tell it what to inject in the Subject line of spams.

As a bonus you will also get MUCH less spam and MUCH less work trying to catch spam with CC rules [:)] 

I would try to see what happens.  It might have a problem with the ' in WHAT'S

if subject contains "can you tell me what*" weight 31

I think this incentive is good. There should be a difference between trial- or unlicensed installs vs. licensed. The licensing work in progress will most likely allow privatees to license.

A correction on MS is that you can download the patches manually and install them, Only a few require authentication to actually install, and there are ways to slipstream them onto a system as well.

Regarding a mailing list, for all unlicensed, the pm-news list and this community is still and most likely always around for announcements, but the latter is mainly a pull method, whereas a list is a push system. Now, email may not reach all, depending on content, format, sender hickups, receiver policies and other hickups that arise from time to time - therefore - a phone-home system within Mercury/32 that is allowed to contact and inform of new releases, then notifying locally that information exists is a very charming way to go. A such system must though be thoroughly tested due to its importance.

Many thanks... :) 

That seems to work well.

The rules look OK. Are you sure the message isn't whitelisted?

Cheers!

-- David --

Thank you, Thomas.

Hmmnn . . Maybe I've got it wrong, but it didn't find anything in my log files.

Like, everything zero.
I pointed it at the MERCyymm.LOG files in LOGS.

Maybe the logfile format changed in V4.51 ?

I have mailed robert, if no response, I will probably knock-up my own version.
As you mentioned, the log-file has the data I am needing, just gotta extract it.

No, you can't suppress these identification items. In actual fact, you wouldn't achieve much even if you could do this - all mail servers have "fingerprints" that are easy enough to track: variations in error strings, responses to different commands and so on.

The version information in the Received: header is very useful to me when doing support and maintenance, and I would be reluctant to remove it.

Cheers!

-- David --

Thanks I'm upgraded to 4.52 without any problems, thanx! mel.

Do not install SMTP-services for IIS at the same machine as Mercury.
The IIS-SMTP listens on port 25 on all bound IP-adresses, and it is very messy to tell it to only use a single IP.

i have SG TCP optimized my server

and now it seems to be all OK

thank you

This behaviour is documented in the Help.

EDIT - I just checked and couldn't find it, maybe I read it elsewhere, but it has been documented somewhere [:)]  - END EDIT

You can specify an action for each CC definition, but if you use X-CC & X-UC headers for triggers in filtering rules you will only get the result of the last CC definition.

Hi Nico

I will install Process Tamer to test.

Thank You

Francisco 

Since it appears that you have isolated the issue to a  queue phenomenon, try running each module manually (note that you may have to press the poll button twice sometimes for it to complete its rounds). Before taking the turn from MercuryD to the Mercury-core, copy the queue files to another location. If the server crashes on every occasion when you poll the core with the queue in place, initiate Thomas or someone else on the beta team here for duplication of your error.

[quote user="Vincent Fatica"]

But I did discover that the queue's QDF file is not locked at daemon call-time and can simply be edited by the daemon.  Now I have a working daemon in place getting rid of the "Sender: Maiser" header.

[/quote]

You MUST NOT DO THIS! This is so much of a problem that if I find that a Daemon is doing it, I will be forced to add code to Mercury to detect and suppress loading of that daemon. Mercury DOES provide a daemon-level method of modifying the raw data files of a job, but it's not shown in the current version of the daemon toolkit. Even so, that is the only approved way of modifying the actual data fork of a job, and you must not attempt to do it "behind Mercury's back" in this way.

The real problem here is the mail program that's trying to reply to Maiser. The RFC822/2822 definition of the Sender: field is quite unambiguous - it must be used whenever the entity sending the message is not the same entity as the one shown in the "From" field - the most usual example is a secretary sending a message on behalf of her boss. It makes no sense for the reply to go to the secretary - the mail program should be sending the reply to the actual author.

I'll consider adding an option to suppress or restructure the "Sender" field in an upcoming version of Mercury, but initially, I'd be trying to find out why the mail client is doing such a bizarre thing.

Cheers!

-- David --