Announcement

Collapse
No announcement yet.

Release to inbox - emails don't arrive

Collapse
This topic is closed.
X
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Release to inbox - emails don't arrive

    I have untangle 14.2.2 in bridge mode. I was getting a lot (more) spam on my exchange server recently, so I installed / switched on the Spam module. I had it running for a week set to mark, and (as expected) messages started to appear with SPAM in the subject.

    I changed from Mark to Quarantine today, and again, all seems ok and emails go into quarantine. However, the issue is, if from within quarantine I select Release to inbox (or Release to inbox & add sender to safe list) the emails never arrive on the exchange server (well, I think maybe 1 out of about 10 did). I have looked at the logs on the exchange server, and there doesn't seem to be any sign of the message trying to get delivered. I then looked at the /var/log/exim4/mainlog log on the unable server, and at the time I did the release of one of them I see the following (I have replaced my domain name with my.domain):


    2019-11-25 20:34:19 1iZL3r-000V6F-ET <= [email protected] H=localhost [127.0.0.1] P=esmtp S=655 [email protected]
    2019-11-25 20:34:20 1iZL3r-000V6F-ET => [email protected] R=dnslookup T=remote_smtp H=my.domain [ipaddressremoved] X=TLS1.0:ECDHE_RSA_AES_256_CBC_SHA1:256 CV=no DN="CN=server.my.domain" C="250 2.6.0 <[email protected]> [In
    ternalId=5047] Queued mail for delivery"
    2019-11-25 20:34:20 1iZL3r-000V6F-ET Completed
    2019-11-25 20:34:40 1iZL3r-000V6F-ET Spool file 1iZL3r-000V6F-ET-D not found
    2019-11-25 20:35:55 1iZL5P-000VHC-CS H=localhost [127.0.0.1] F=<[email protected]> rejected after DATA: maximum allowed line length is 998 octets, got 3887

    I have untangle set to "Send email using the specified SMTP Server" (but the same happens with it set to "Send email directly").

    Clicking the Test email button works, and also getting the daily reports email works ok, so it seems something specific to releasing quarantine emails.

    Anyone seen this before / have any ideas?

    Thanks,
    Ian.

  • #2
    You need to check your Exchange SMTP logs and figure out WTF it's doing with it. Because if the test messages work, the problem is on the mail server.
    Rob Sandling, BS:SWE, MCP, Microsoft Certified: Azure Administrator Associate
    NexgenAppliances.com
    Phone: 866-794-8879 x201
    Email: [email protected]

    Comment


    • #3
      I have turned on SMTP logging on the exchange server. I had about 8 emails in Quarantine, so (one at a time) I released them. About 3 or 4 did get through, and I can see the connections in the SMTP log on the exchange server. For the others, there isn't anything in the logs to show that a connection was made (attempted). Think I will try a packet capture on the untangle box to see what (if anything) goes out when one fails.

      Comment


      • #4
        If you want to see the log from Untangle's perspective, it's /var/log/exim/mainlog
        Rob Sandling, BS:SWE, MCP, Microsoft Certified: Azure Administrator Associate
        NexgenAppliances.com
        Phone: 866-794-8879 x201
        Email: [email protected]

        Comment


        • #5
          That's the log I mentioned in the 1st post (well /var/log/exim4/mainlog).

          When it "fails" that log shows:

          2019-11-26 14:31:39 1iZbsR-000XaY-Kp H=localhost [127.0.0.1] F=<[email protected]> rejected after DATA: maximum allowed line length is 998 octets, got 1262

          when it works it shows:

          2019-11-26 14:08:36 1iZbW8-000W4d-OG <= [email protected] H=localhost [127.0.0.1] P=esmtp S=5747 id=CX-hCMj9OAXU3mrkoPGWHboJuwp1V4aFztik1UqN6AE.3sERYqmIQndfSDCwwxCR2YlcAqliQZ02Of76NcltxZc@sing
          legloom.icu
          2019-11-26 14:08:37 1iZbW8-000W4d-OG => [email protected] R=smarthost T=remote_smtp_smarthost H=10.10.10.10 [10.10.10.10] X=TLS1.0:ECDHE_RSA_AES_256_CBC_SHA1:256 CV=no DN="CN=server.mydomain.local
          " C="250 2.6.0 <CX-hCMj9OAXU3mrkoPGWHboJuwp1V4aFztik1UqN6AE.3sERYqmIQndfSDCwwxCR2YlcAqliQZ02Of76NcltxZc@singlegloom.icu> [InternalId=5140] Queued mail for delivery"
          2019-11-26 14:08:37 1iZbW8-000W4d-OG Completed

          Comment


          • #6
            The relevant bit is: rejected after DATA: maximum allowed line length is 998 octets, got 1262

            Your Exchange server is booting the message because it's too big. So yes, you should have a matching event on the Exchange side that shows this.
            Rob Sandling, BS:SWE, MCP, Microsoft Certified: Azure Administrator Associate
            NexgenAppliances.com
            Phone: 866-794-8879 x201
            Email: [email protected]

            Comment


            • #7
              Yes, that's my thinking, but there doesn't seem to be a matching event, hence why I thought I would do a packet trace to see if anything is leaving the untangle server.

              Comment


              • #8
                (by the way, this is only a home setup, so not critical, I was just putting it out there in case anyone had seen this before / had any ideas).

                Comment


                • #9
                  Back when I had my own mail server, Untangle had its own connector so I could avoid stuff like this.

                  But I can't tell you where the settings are anymore, because I've long since Office 365'd all the things. I have no interest in going back to an internal Exchange deployment.
                  Rob Sandling, BS:SWE, MCP, Microsoft Certified: Azure Administrator Associate
                  NexgenAppliances.com
                  Phone: 866-794-8879 x201
                  Email: [email protected]

                  Comment


                  • #10
                    Waited severial hours, and a load more messages in the Quarantine area. Released messages while doing a packet capture (looking at port 25). The first few I released did get sent ok, and packets were captured. Then one didn't get sent (with the mainlog having the "rejected after DATA:" bit ) and no packets were captured.

                    So, strange as it may seem, it seems that when a message fails to send, it's not even going out from the Untangle server. Wonder if the Quarantine area is trying to submit it to a SMTP queue within Untangle for it to be sent, and it's this that's causing the "rejected after DATA:" error.

                    Comment


                    • #11
                      Well, I'm not a dev but that's probably true. Exim is the SMTP queue for Untangle. And if it's trying to move too many mails at once, it will throttle itself.

                      I'd open a ticket and let support poke at it, might be a bug, might be a load issue. No way we're going to solve it here either way.
                      Rob Sandling, BS:SWE, MCP, Microsoft Certified: Azure Administrator Associate
                      NexgenAppliances.com
                      Phone: 866-794-8879 x201
                      Email: [email protected]

                      Comment


                      • #12
                        Heard back from untangle support, seems that this is occurring because the message(s) that have been released (and failed) are actual spam.

                        As I said, after setting up Quarantine for the first time, I tried to release a message (that was probably spam) and got this error, and because of that I was releasing more messages than usual to test, and most of these messages have probably been real spam, hence why seeing the error more.

                        From now on I would expect to only release “true” messages, and as such this error should hopefully not occur.



                        Below is some information regarding why this is occurring:

                        550 maximum allowed line length is 998 octets, got 1014 Getting this error in emails bouncing back. Is there a setting in exim to solve this problem? Tried to google it up but cannot find any sol...


                        This is due to the released email being actual spam, and Exim is denying the send due to RFC standards of size.

                        Comment


                        • #13
                          I wouldn't say that's spam, I mean it is... but the real problem here is an envelope that isn't formed correctly. Fascinating...

                          And yes, Exim wouldn't like that. So you can't release malformed junk mail, even when you want to! That's kind of cool, if you're expecting the behavior. Thanks for reporting back.
                          Rob Sandling, BS:SWE, MCP, Microsoft Certified: Azure Administrator Associate
                          NexgenAppliances.com
                          Phone: 866-794-8879 x201
                          Email: [email protected]

                          Comment

                          Working...
                          X
                          😀
                          🥰
                          🤢
                          😎
                          😡
                          👍
                          👎