1 of 1 people found this helpful
first of all I would add an event to the rule that sends the eMail that writes an entry into a logfile, so that you can proof that the rule was really executed. If there are already other Events that send an eMail I would check if there is the "duplicate Mail prevention" turned on and preventing the mail from being sent... the easiest would be to simply turn the protection off for testing.
Finally check the settings for SMTP server etc. again. A wrong DNS name may cause the DNS lookup to fail and MWG will not connect to port 25, so make sure MWG can resolve the name (try telnet my.smtp.host 25).
If that is all given run tcpdump -i any -s 0 port 25 and trigger the event again.
If that all won't work, ask support :-)
I'd done most of the other things, but hadn't added an event to the rule itself to write to a log file. Tried that today and the test rule is definitely firing as I had seen by enabling rule tracing.
Duplicate email prevention is disabled.
The SMTP destinations are defined in /etc/hosts.
telnet smtphost 25 and ping smtphost work fine and it's possible to manually send an email through both of the configured relay hosts.
tcpdump -i any -s 0 port 25 shows no traffic leaving MWG related to the rules firing. It does show traffic if a manual connection is made via telnet.
Nothing in output from mwg-core -L showed anything glaringly obvious.
service mwg-core restart resulted in messages being sent again.
if the restart causes mails to be sent again my first thought would go back to the duplicate email prevention. It is hard to tell because you cannot see the status of the duplicate email prevention, but - apart from a bug - I can't think of anything preventing MWG from talking to the SMTP server and send the mail.
Do you have multiple Settings for the SMTP Server? Probably one of the has the duplicate prevention still enabled. I am not completely certain but I think the duplicate mail prevention may not be tied to the setting explicitly. Also if the duplicate prevention is turned on and "active" (e.g. a mail has been sent) I believe turning it off will not make all new mails flow, but MWG would still wait until the "active" prevention is timed out.
If you turn off all of the duplicate preventions and restart they should be gone. In that case the mails should flow as expected. Can you replicate the issue with all preventions turned off?
There was a Default config with duplicate mail detection enabled. I changed that config.
Unfortunately, I cannot replicate the problem at will. I only noticed it because a report that uses the raw log data showed me something for which I had not received an email alert.
At the site with the proxies that weren't sending email, one of the systems had sent an email as recently as two days before I noticed there was a problem.