4 Replies Latest reply on May 24, 2013 12:13 AM by btlyric

    Email.Send doesn't send -- how to debug?

    btlyric

      We have MWGs in multiple locations. In two of the locations, email notifications via Email.Send are working fine. In the third location, even though the criteria needed to trigger an Email.Send event occur (and are logged by rules in the same rule set), tcpdump indicates that there is no tcp/25 traffic leaving the boxes at that location.

       

      I can't find any error messages in any log files.

       

      Where should I be looking?

        • 1. Re: Email.Send doesn't send -- how to debug?
          asabban

          Hello,

           

          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 :-)

           

          Best,

          Andre

          1 of 1 people found this helpful
          • 2. Re: Email.Send doesn't send -- how to debug?
            btlyric

            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.

            • 3. Re: Email.Send doesn't send -- how to debug?
              asabban

              Hello,

               

              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?

               

              Best,

              Andre

              • 4. Re: Email.Send doesn't send -- how to debug?
                btlyric

                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.