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.

[quote user="briankelly63"]

Is this limitation still exist with the 4.62 release. ie: do you still need two entries?

 Yes, you still need two entries

Thank You,

Brian

[/quote]

Hmm probably an oversight during testing. I have this too in my logs during the beta periods in may. It shouldn't be reported as abnormal.

However after David fixed the last memory issues with his memory tracer we haven't had any reason to automatically restart Mercury each night.
After having shut down this feature we have no abnormal terminations in the logs.

Also, if all your users are all on a local network (or known ip addresses) you can set up a mercS transaction filter to reject (& blacklist) MAIL FROM local users.

e.g.

 M, "*@your.domain*", BS, "554 Fraudulent MAIL FROM"

 

Just make sure to exempt your local ip's from the transfilter in the SMTP - Connection Control tab

I have a couple of users outside on dynamic ip's so have put exceptions for them BEFORE the reject rule

 M, "*dyn.user@your.domain*", X, "MAIL FROM accepted"

This leaves a hole in this method but these particular users don't get hit much and Spamhalter has cleaned up any that did get through like this. 

In this case it appears to be Mercury answering on port 110, though. As Thomas said the best thing to do is to check the logs.

/Rolf 

[quote user="PaulW"]

[quote user="Thomas R. Stephenson"] I'm not saying that Graywall does not affect the level of spam received via SMTP, it does.  However it's getting less effective based on my data.[/quote]

How effective it is surely must be to do with how the spam is being sent.  For me greylisting is still very useful against botnets of compromised user machines, but it has never been much good at stopping open relays or compromised servers.  I get quite a bit of that type and since they *are* proper servers, they will retry and get around any greylisting software.  For that sort of spam, you have to trust in DNSBL or other methods.

[/quote]

Looking at the connecting IP addresses of the sending systems it is apparent to me that many of these are coming from a botnet machine.  Based on the IP address I would probably would be able to block many of these if I were to use a blacklist listing the randomly assigned IP addresses but that would block many SMTP servers as well sending good mail. 

Like I say it has reduced my level of spam coming in directly but there are more and more spam systems that retries as required by the RFC.  Also it appears that the spammers are sending their spam through the infected systems SMTP host as well and these systems always retry.

This is all pretty academic anyway, 99.8% of the spam never gets to the user mailboxes anyway since it's blocked by POPFileD. 

 

 

 

 

Hello Thomas,

 using LDAP synony doesn't mean to implement LDAP on your Server. David calld it (I think so) that way, because the attribute was introduced with the LDAP Support of NDS. Pmail / Mercury use native NDS call to access that attributes. My tests also show, that both programs use the same Attribute: Internet EMAil Address in NDS Schema, which is mapped to the LDAP interface of NDS to the Ldap Attribute mail.

I recommend to either not load NLDAP.NLM if you don't use it (no Imanager, no Ldap contextless Login, no ....) or to configure your Firewall (FILTCFG.NLM) to not allow Ldap from outside. The last is what I do.

 Klaus

Great! [:)]

[quote user="Moshe"]

Hi Thomas,

I did enable the password feature and am using the correct syntax in the "to" field ( where "spam" is the account, "password" is replaced by a real password and the "site" is replaced by the site name).

 The thing is, the spamhalter config page says "password for offsite corrections" and I do specify the password...

 I am sending the correction mails using an authenticated (password on SMTP) account.  I'm using the same domain for both the server and the mail account.

I'm still confused as to what's wrong.

[/quote]

 

As am I.  I do exactly what you are doing when sending the mail to Spamhalter.  The logs show that the correction is being made using the password.

D 20071116 110119.824 MG000004 Mercury version >= 4.1
D 20071116 110119.824 MG000004 jobfile: C:\MERCURY\QUEUE\MG000004.QDF
D 20071116 110119.824 MG000004 spamdir: \\THOMAS\SYS\MAIL\6000001
D 20071116 110119.824 MG000004 nospamdir: \\THOMAS\SYS\MAIL\7000001
D 20071116 110119.840 MG000004 origin by MercuryD
  20071116 110119.840 MG000004 from: support@tstephenson.com
D 20071116 110119.840 MG000004 > Internet sender
D 20071116 110119.840 MG000004 > Need to test
P 20071116 110119.840 MG000004 Correction enabled by password
_ 20071116 110119.840 MG000004 Correction request saved as: \\THOMAS\SYS\MAIL\7000001\AAB85WGU.CNM

My only guess is the password is wrong on your setup..

 

You're right, I put a wrong CIDR notation for my own local network in SpamHalter config!

Now everything is working as expected. Thank you for your help !!