[quote user="ldsandon"]

What about the other vulnerability Secunia lists since March? 

[/quote]

Secunia's data is out of date, this more serious vunerability was fixed very quickly and anyone running 4.01c or 4.52 isn't vunerable.

David

 

[quote user="CobraA1"]

Thanks. I now have a direct to my PC email with a fall back to my domain name provider.

I do have a question, though: When sending email, is it possible to set it up so that it is direct, but falls back to a relay if direct doesn't work?
 

[/quote]

 

No but if you run your own DNS system you can set the IP address for the AOL (or any other host that blocks your connection) MX host to your relay hosts IP address so MercuryE will deliver the AOL mail to the relay host.

 

That was what I was doing.  The remainder of the template works correctly, but the "From:" header in the template is being replaced by the mailbox name.  What I was trying to do was to send "change of address" notices for a pop account by delivering them to a pass-through account, forward them to the intended recipient, but send an address change notification to that fraction of the intended recipient's mail that went through the pop account...but to avoid having the address change make any reference to the intermediate account.

 

I have since upgraded to 4.52, and not yet tested to see whether the problem still occurs. 

OK Thanks.
I'll filter when the email has arrived.
 

Nope.  Sadly, I'm paying for this honor.  That does make sense though.

 

We have run Mercury 4.01b on Windows 98SE and Windows XP Pro and now run 4.52 on XP Pro. We have used POPFileD v1.22.4 with POPFile v0.22.4 on both Mercury 4.01b and 4.52 with both Windows 98SE and Windows XP. In every case POPFile's use of SQLite results in lots of 0k locked files that do not go away until POPFile is shutdown. These files are in "C:\Windows\Temp" for Windows 98SE and are in "C:\Documents and Settings\MercuryAccount\Local Settings\Temp" for Windows XP. It appears like a file is created and locked for every email that passes through POPFile. Each file is named something like "sqlite_nwkhQ5SvfzHf0Wa" and has a size of 0k. The file cannot be opened by Notepad or even merely copied to some other location because it is locked. Several hundred or even several thousand of these files may accumulate over a period of several days and then no more accumulate and the ones that are there just stay there indefinitely until POPFile is shut down. For example, I last started POPFile (and Mercury) on Sept 8. There are over 800 of these locked files with dates from Sept 8-13 and then no more. If POPFile were shutdown all these locked files immediately go away.

Has anyone else noticed this phenomenon? Is it a POPFile, POPFileD, or SQLite bug? Or is it something else? And does anyone have a solution to suggest? I get the impression that the system seems slower when there are many of these files sitting there.

FWIW Pegasus & Thunderbird (custom version from portableapps.com) can be installed on a USB thumbdrive so you can have your mail client in your pocket [:D]

Will work from any PC you plug it into without installing. (Local firewall & USB security policy may be an issue in some cases though.) 

[quote user="Marschall"]

why has the queue handling been changed fom FIFO to LIFO since V4.5 ?

[/quote]

It hasn't!  In fact, there has never been a firmly-defined processing order in Mercury. If you were getting a FIFO effect before, then it was purely a curiosity of the way the files were organized on your system. MercuryE does a certain amount of queue sorting to ensure that old, slow mail doesn't unnecessarily delay mail recently injected into the queue, but it's fairly slight and if I recall correctly, was done in v4.0 anyway.

The order of jobs in the queue is pretty much determined by the order in which they are returned by the operating system.

Cheers!

-- David --

[quote user="aka_bigred"]

I'm trying to figure out how to configure M32 to use the same name, say admin but for different users on different domains.  I want to have 3 users named "admin" - each one a unique user/mailbox on each domain.  Here's my example:

    admin@mydomain1.com --> Tom Jone's Mailbox

    admin@myotherdomain.com --> John Smith's Mailbox

    admin@onelastdomain.com --> Jane Smith's Mailbox 

If I understand the documentation correctly, M32 is setup so that all users are automatically setup with same account across all domains.  When I setup the local user "admin", I get:

    admin@mydomain1.com --> Tom Jone's Mailbox

    admin@myotherdomain.com --> Tom Jone's Mailbox

    admin@onelastdomain.com --> Tom Jone's Mailbox

 

How can I setup M32 for the first scenario with the same external username across multiple domains but different users. ? 

[/quote]

 

You need to use aliases.  Create three users admin, admin2, and admin3.  You then alias admin@myother domain.com to admin2@myotherdomain.com and admin@mylastdomain.com to admin3@myotherdomain,com

 You can also make these usernames something like admin_dom1 is you wish to make them more specific to the domain.

 

Thanks.  I'm not sure what version of Mercury he's using, but it should be fairly recent.

What is the advantage of receiving mail via SMTP versus POP3?

POP3 is a single user protocol.  With a single user it's no big deal how the mail is received but when trying to manage multiple users in a single POP3 mailbox the difference is huge.  Mail is delivered  using the SMTP headers and so it does not make any difference at all what is in the body of the RFC 2822 message.  You also have the ability to use SMTP blacklists and graywalling to block the spam at the server rather than having to download and process the mail. 

Why VPN?

Just forward a (non-standard if you like) port to your merc at home and have your work or mobile client get it from there rather than your ISP.

POP3 or IMAP, whatever blows your hair back.

(I have assumed an always on connection & static ip or dyndns since you mentioned VPN-ing in [:)])

If you've installed IIS-smtp service they can't coexist with Mercury unless you tell Mercury to use an alternate port - or you have to hack the IIS-smtp config (messy...)

Mercury will by default use the DNS servers specified in Windows for domain name lookups. It's possible to select other DNS servers in the MercuryE (SMTP End-to-End delivery) module if you prefer that. In either case the IP numbers of the DNS servers used should be shown in the MercuryE log window on program start.

As there was a MX lookup failure you need to verify that all IP numbers entered for DNS servers are correct.

Apart from that I would add the public IP of your system to the Domains section as well (presumably [64.20.35.155]).

/Rolf
 

No, you can't access message headers in the SMTP transaction filter. It would probably be possible to create a daemon to do it with the new, not yet publicized daemon interface, though. Still I'm not sure it's always wise to reject on mismatch here; a redirected message might have the mail address of the person redirecting it as SMTP MAIL FROM.

/Rolf 

[quote user="subelman"][quote user="Thomas R. Stephenson"]

I use NT Wrapper to run Mercury/32 as a service with POPFileD and then run POPFile as a service as well as described on the POPFile pages.  I've not had any problem at all with this type of setup for over a year or so.  With NT Wrapper I am running the Mercury/32 service as a specific user since I need to specify the username and password to authenticate to the servers.  NT Wrapper allows me to specify the specific user and still allow the GUI interface.

[/quote]

In my experience, when the machine is rebooted, POPFile takes much

longer than Mercury to start, sometimes up to 60 seconds longer. If you let

them both start as services, then Mercury will start first, and until

POPFile is up, you won't have any spam filtering.

I worked around

this by starting Mercury via a batch file, that just waits for a while before starting Mercury. That delay allows POPFile to be up by the time

Mercury comes up. But I could not get this to work as a service.

How do you handle that issue?

[/quote]

I ignore it.  ;-)  My system is running on a UPS and does not go down all that often for any reason.  If it does my MX host takes at least a minute or so before it starts spewing queued mail and finally if I miss classifying a couple of spams in that first minute or so it's no big deal anyway.

FWIW, I've found that both start at pretty much the same time when running at a service when the system comes back on line.  POPFile is running as a native service and NT Wrapper probably makes Mercury/32 a bit slower to get started on boot up, especially when it is logging in as a user as well.

 

This issue has indeed been solved in v4.6!

I had a test setup that invariably replicated the problem in v4.5. This morning I upgraded this test environment to 4.62, just to make sure, and the problem has vanished.

Bart

Thanks

I realised after I posted !!
 

I created the batch file (follows) and inserted DOS SET EMAILADD="%Internet Email Address" in the login script. If version 1.12 of the headers extension is used, the sending hostname is pasted to all outbound messages. I run the batch using ZENworks but could easily be done from any login script. etc.

 

@ECHO OFF
echo [%EMAILADD%]>U:\PMAIL\headers.pm
echo header1=Received: from %COMPUTERNAME%>>U:\PMAIL\headers.pm
CLS
@EXIT

[quote user="m.fessler"]

Thanks Rolf for confirm this problem.
Maybe a bug?

Its look like a file access thing... so i cannot delete the files in the queue folder until i close mercury because there are open.
So maybe Mercury has the same problem....?!

Regards,
Martin

[/quote]

I doubt if you really can call this a bug since it's really a limitation of the system.  I suspect the filters, like all the other filters,  work on the RFC 2822 QDF file, they do not get the control QCF file and or QIF info file.  It appears you are deleting/moving/removing the QDF file from the queue but of course the other associated files are left.  The daemons get both the QCF and QDF files so they could probably handle this type of process.  Probably the outgoing mail filter should not be allowed to remove any mail from the queue this way.