MercuryE has no size limit but the receiving SMTP server can have one. It's not likely to be as small as 32 KB though, so the problem is presumably as you suggest elsewhere.

[quote user="PaulW"]My attachment rules work, although I don't use them for checking for bad extensions.

Is there any way those messages won't pass through that filter?[/quote]

My attachment rules work as well.  The base64 encoded .zip file I referenced in the original post is the first .zip file I have seen come through the filter.  I have to assume the filter is looking at something other than the ".zip" content in the filename that is going undetected due to the encoding but would like to know for sure to see if I can come up with another way of removing such attachments.

This appears to have been resolved. The support guy added the 'our-domain-name.l.google.com' to the domains list and added their MX records to the delivery details. I've just sent a test message and have not received a delivery failure notification. I had not realised we could add this domain and specify a different delivery address.

There is as far as I know no daemon interface or similar to manipulate the access control list for MercuryS or reload the ACL file. Another approach could perhaps be to write an event daemon to log relevant AUTH request data. 

Thanks a lot for the tip...

I will also have to work arround with SPF's for other vhosts on this testing server, before installing on the production server... 

One more time thanks a lot..... 

With the best regards of Aquiles Crespo 

Thanks Rolf. I was able to hit the Gmail SMTP server from the command line on my server. I went back and removed the string in the Announce As field and mail started going through.

Thanks for your help!

Harry 

I had an issue a couple of days ago when one of our remote workers said they were unable to send mail. IMAP was working fine, so they could receive, but SMTP was not so they were unable to send mail. When trying to send (via Thunderbird), a message was displayed asking them to re-enter their password.

I opened the SMTP_Auth.pw file under the MercuryS configuration 'Connection control' tab to grab the password but it was empty. I located the file itself in the Mercury folder and saw that all the username/password entries were present.

Restarting Mercury reloaded the file and the remote worker was then able to send mail. Mercury had been up for about a month which is the average time it is running before being restarted as part of the server's Windows Update installation schedule.

Just posting this in case anyone else has the same issue.

[quote user="syndrical"]

What I'm trying to achieve is the following example:

User A has an account in the system but doesn't have an email address. When an email comes in, I'd like a PHP file to analyze the email & if the user is in the database, then store pieces of the email in the database. I already have the code for the PHP file but how do I get the file to run when an email comes in? Currently Mercury sees that the user doesn't have an inbox and says the email is undelivered. How can I get around this?

I've tried a policy but it doesn't seem to work.  

[/quote]

For a policy to work the email first has to be accepted as valid for the server. Why can't the user have a proper mailbox on the server?

Brian,

I'm sure I have been reading a similar question somewhere in this forum. The answer was no, Mercury POP3 client has no option like "keep mails on server for xxx days" like e.g. Thunderbird has.

I had a similar problem when I wanted to read my office mails at home using IMAP access from my providers mailbox. The solution was to forward / duplicate all incoming mail to a separate mailbox already at provider site.

Bernward

And there is my n32comm.bat - as attachment nr.2:

 @echo off
REM 2016-03-06 SP.
: Rem - %1 is the file to scan %2 is the name of the result file %3
: Rem - is the sentinel file. The report from the scan is sent to the
: Rem - Result file. If No virus is found then the Result file is
: Rem - deleted prior to deleting the sentinel file. If a virus, or
: Rem - other error is found, then a message indicating the meaning
: Rem - of the return code is tacked on to the end of the result
: Rem - file. Deletion of the sentinel file is the last thing that
: Rem - takes place.
: Rem - Note 1: Some of the error codes should never occur, in this
: Rem - context, but I put them in anyway for documentation purposes,
: Rem - if nothing else.
: Rem - Note 2: There's colons in front of the Rem statements because
: Rem - blank labels process faster than Rem statements (the entire
: Rem - Rem statement is parsed even though it's a comment)
: Rem - No extended batch command features are used so this should
: Rem - work with*any* MS OS.
: Rem - Watch for wrapping of the batch file lines in this email
: Rem - message.  They are longer that the normal 70 CPL!.  The
: Rem - ECLS.exe commandline and echo line should NOT be wrapped.
: Rem
REM ESET File Security directory - Path to ecls.exe :
"c:\Program Files\ESET\ESET File Security\ecls.exe" %1 /arch /sfx /rtp /adware /unsafe /unwanted /pattern /adv-heur /clean-mode=delete /mail /log-file=%2
If Errorlevel 100 goto error100
If Errorlevel 50 goto error50
If Errorlevel 10 goto error10
If Errorlevel 1 goto error1
REM If none of above, deleting the result file:
Del %2
goto Ende

:error1
echo 1- threat found and cleaned >> %2
goto Ende

:error10
echo 10 – some files could not be scanned (may be threats) >> %2
goto Ende

:error50
echo 50 –  threat found >> %2
goto Ende

:error100
echo 100 error >> %2
goto Ende

:Ende
if %3.. == .. goto LastEnd
Del %3

:LastEnd
exit

Mercury needs PMAIL.USR to contain a list of all mailboxes. If it's been corrupted the best solution would be to restore it from a backup. If none is available you can recreate it using Notepad. First line is usually:

A;Admin;Mail System Administrator

Then add one line for each mailbox like this:

U;username;Personal Name   (for instance U;mike;Mike Mailman) 

Thanks for the update Joerg.  Am glad Spamhalter is working for you.

Happy Easter to you as well.

You couldn't be more wrong about this, Devon:

 "outgoing authentication" has absolutely no effect on mails addressed to local mail addresses. Think yourself: How would a foreign MX deliver mail to your local domains if it had to AUTH?

Just to update as this was posted on the mailing list as well: The ISP is currently investigating why traffic on port 25 apparently is blocked.

Thanks Rolf.  I think I know what's happening here.  For the account in question, all mail is intentionally being forwarded from another server (I cannot easily change this).  So, the immediate connection to Mercury is not from a spammer's server but from this forwarding host.  I don't think that connection control is going to help me in this situation.

Unfortunately, I haven't yet found any of these recent spamming hosts blacklisted, when checking with whatismyipaddress com, so Mercury's blacklist feature is not going to help either.

Gordon 

Just a confirmation, in case anyone else has this problem; the cause and the fix I've posted appear to work, the only downside being that access to my website requires using www in front of the domain name, previously it was optional. an alternative fix might be to set up a forwarding email account with my hosting provider but not create an MX record to point to it. The reason for no MX being that the spam that I refuse connections to will end up there and get forwarded to me.

DOH!  That "Example" line has bitten me in the butt before.  You would think I would learn.

Thank you!

FYI...

Clamav v0.99.1 release announcement:

http://blog.clamav.net/2016/03/clamav-0991-has-been-released.html

[quote user="Devon P"]

I use a program called peerblock to create my own custom allow and block rule lists and just use notepad++ to edit the lists. Easy to setup on the fly once master it. My custom block list now over 17K lines long. Peerblock is just a glorified firewall program that works with windows firewalls and dont have to create custom rules every time as this program listens on text file lists and populates the block list itself.

We had a massive problem with spammers worldwide, so we had to block all country's world wide besides the US and just allow certain domains and ip addresses from outside the US.

[/quote]

Ah - this would not work for the OP as Peerblock blocks IP addresses. You'd need some sophisticated traffic analysis to successfully allow mail from one IP address to just one domain.

Thanks. Seems SSL/TLS is involved. Turned it off and this worked for most accounts. For the last I renewed the passwords and this seems to have solved the last.

Also repaired the 4.80 install, knowing now that I couldn't brake anything.

If I've another moment I'll reimplement SSL/TLS.

Thanks for the guidance.