DMARC rejections leave '.hdr' files in proc directory
Problem reported by Fred Needham - December 14, 2017 at 1:35 PM
Submitted
SmarterMail Enterprise Edition Version 15.5.6222 with Declude
 
When a email logs "Data transfer succeeded but message rejected by DMARC" and one is using "Enable spool proc folder"(Antispam Administration- Options), the '.hdr' file is not deleted.
 
I checked "Enable DMARC policy compliance check" a few weeks ago. From the logs I can tell that 10-50 emails per day are being rejected; however, each time a message is rejected, a '.hdr' file is left in my 'proc' directory (d:\smartermail\spool\proc)

4 Replies

Reply to Thread
0
echoDreamz Replied
Welcome to Declude. We had this happening CONSTANTLY. We stopped using declude, the issue went away.

Christopher

0
John Reid Replied
This is still a problem. Every 3 months I clean 150,000 .hdr files out of my proc folder. I am on SmarterMail Enterprise Edition Version 15.7.6572 with Declude and MessageSniffer

Linda over at Mail'sBestFriend has looked at this a couple of times for me. No resolution, except maybe create a PowerShell script to cleanup .hdr files more than a couple days old and let it run from task manager every night. David and Linda do their best to keep Declude going for us, but it has been dead for a very long time now.

P.S. if anyone needs a Microsoft Word version of the Declude documentation, I have one. PM me for a copy.
0
Fred Needham Replied
I reported this issue to Smartermail as part of a larger report of Dmarc issues. Smartermail replied that it is the responsibility of the 3rd party product to delete the HDR files. So I wrote a short program to delete all HDR files will 'Failed' in them. I run the program hourly with a scheduled task. I think Smartermail is wrong! Why delete the EML file but not the HDR file when an email is rejected due to Dmarc. I think Smartermail should delete them both.
0
John Reid Replied
Fred, this is an issue that goes back years. Not just to December of last year. By the time you reported this they had already moved on to SmarterMail 16 and are look forward at 17. Good luck getting any traction there. Your solution is likely the best you are going to get here, but possibly a little overkill. I don't think you need to look for 'Failed', and I don't they they build up so fast you need to run hourly. If the file is still there after a few days, kill it. If you want to really play it safe, delete anything older than the time you have set for your spool retries. Mine is just over 4.5 days, so if it is 5 days old, it is not getting any more delivery attempts anyhow. That is just my opinion though.

Reply to Thread