This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

How to deterime the cause for rejected after DATA

Hi,

is it possbiel to get to know, what triggered the AMG to reject a message? I have a client who deperately waits for a message that gets continously rejected on the AMG. The smtp_proxy logs shows this:

2009:03:23-10:21:40 astaro01 exim[28111]: 2009-03-23 10:21:40 1LlgLk-0007JP-1S id="1003" severity="info" sys="SecureMail" sub="smtp" name="email rejected" srcip="212.1.38.25" from="foo%40bar" to="bar%40foo" subject="PreSafe" queueid="1LlgLk-0007JP-1S" size="123815" reason="as" extra="confirmed"
2009:03:23-10:21:40 astaro01 exim[28111]: [1\48] 2009-03-23 10:21:40 1LlgLk-0007JP-1S H=mx2.jvm.de [212.1.38.25]:40157 F= rejected after DATA

Thanks,
budy


This thread was automatically locked due to age.
Parents
  • Hi,

    i´ve encountered an issue with the realtime blacklist check. Our astaro has dropped emails even the sender is defined in the whitelist.
    We used the recommended rbl feature.
    After turning off this feature emails were processed as expected.

    Some of the default rbls (sbl-xbl.spamhaus.org) are not reachable.

    Regards,
    Clemens
  • That might be the case, but obviously the AMG doesn't tell what specifically has triggered what ACL.

    And… shouldn't the AMG reject each message if a rbl doesn't answer, not just messages from a specific sender?

    Cheers,
    budy
  • Since this affects both 7.3 and 7.4, it is apparently due to the pattern updates from European servers.  One of you with support needs to report this bug to Astaro Support.  We are not seeing this phenomenon in the Americas.

    Cheers - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • With the rejects I mentioned above the complete envelope appears in the log, too. As we are only gold-licensed someone else have to tell Astaro [:(]
  • Also got the NDRs of two customers today: #5.5.0 smtp;550 Administrative prohibition>

    Checking the reputation of the IP's at commtouch today revealed: These IP's are NOT known Spam senders (anymore today?). Still the mails have been filtered out. So this is not consistent in its behavior / cause.
    There is quite a lack of information the ASGs provides us here with. [:(] 
    The report in the mailmanager still tells just as much as a blank white window can tell... nothing.

    Would be fine if someone could post results of a probable call with Astaro.
  • Hi t-work,

    have you read my two posts?
    Have you tried one or both of them?

    cu SveN
  • I have exactly the same problem with all my customers!
    rejected after DATA.

    Even if I send an email to Peter Vogt its Astaro blocking my mail!!!![:O][:O]

    : host mx.astaro.com[213.144.15.13] said: 550 Administrative
        prohibition (in reply to end of DATA command)

    [:@][:@]
  • Hmm, that's not exactly the same problem, that has been discussed in this thread. Your transmission has been rejected at the end of data not right after, which points to the pre-Data SPAM check.

    If the message gets rejected at the end of Data sequence, there might be some other checks involved or maybe the recipient could not be verified.

    Cheers,
    budy


  • [QUOTE=SveN;106663%5DHi have you read my two posts?
    Have you tried one or both of them?]

    [QUOTE=SveN;106663%5DHi cu SveN


    I am sorry to answer you that late:
    I have read your posts, but thought you are talking to budy exclusively :-)

    I don't know what the tcpdump would help me? I assume the ctasd filtering too strictly all of a sudden. (What still concernes me is that there is no evidence and no possibility to troubleshoot the issue with this ctasd-filter) Also I can't know which connection to log - sometimes we even get mails from IPs that have been blocked repeatedly just a few hours ago.

    Turning off filtering for some senders' domain seemed to work. But I have no proof of that: we GOT mails of one customer after adding him to the exclusion list, but the testmail has been sent one day after the first occurrence. After turning off the exclusion again mailing still worked. I am not able to test with all customers that are concerned by this.

    I will check my logs daily until there is a fix for that - at the end of last week it seemed to be better. I have not gone through my logs today - yet so lets see...

    regards and: thank you!
  • It looks like the filters are working OK now.

    I am keeping an eye on that issue and will report if something changes.
  • I am having some inbound emails being dropped, which is very concerning as we are not sure if clients think they have sent emails to us, but we have not received them. I did a test with a supplier who's emails have been rejected, and the logs show the following.

    Can anyone help me with this before I get the MD firing me!

    Regards

    Dave

    2009:03:31-14:34:21 (none) exim[30834]: 2009-03-31 14:34:21 1Loe6e-00081K-2Z ctasd reports 'Confirmed' RefID:str=0001.0A0B0206.49D214E2.02A8,ss=4,sh,fgs=0
    2009:03:31-14:34:21 (none) exim[30834]: 2009-03-31 14:34:21 1Loe6e-00081K-2Z id="1003" severity="info" sys="SecureMail" sub="smtp" name="email rejected" srcip="212.42.162.167" from="james.gillies%40softek.co.uk" to="Dave.Pritt%40saunderson-house.co.uk" subject="Testing%20123" queueid="1Loe6e-00081K-2Z" size="4107" reason="as" extra="confirmed"
    2009:03:31-14:34:21 (none) exim[30834]: [1\34] 2009-03-31 14:34:21 1Loe6e-00081K-2Z H=mailfilter7.fast.net.uk [212.42.162.167]:50841 F= rejected after DATA
    2009:03:31-14:34:21 (none) exim[30834]: [2\34] Envelope-from: 
    2009:03:31-14:34:21 (none) exim[30834]: [3\34] Envelope-to: 
    2009:03:31-14:34:21 (none) exim[30834]: [4\34] P Received: from mailfilter7.fast.net.uk ([212.42.162.167]:50841)
    2009:03:31-14:34:21 (none) exim[30834]: [5\34]  by astaro2.saunderson-house.net with esmtps (TLSv1:AES256-SHA:256)
    2009:03:31-14:34:21 (none) exim[30834]: [6\34]  (Exim 4.69)
    2009:03:31-14:34:21 (none) exim[30834]: [7\34]  (envelope-from )
    2009:03:31-14:34:21 (none) exim[30834]: [8\34]  id 1Loe6e-00081K-2Z
    2009:03:31-14:34:21 (none) exim[30834]: [9\34]  for Dave.Pritt@saunderson-house.co.uk; Tue, 31 Mar 2009 14:34:20 +0100
    2009:03:31-14:34:21 (none) exim[30834]: [10\34] P Received: from bart.softek.co.uk (bart.softek.co.uk [213.133.199.50])
    2009:03:31-14:34:21 (none) exim[30834]: [11\34]  by mailfilter7.fast.net.uk (8.14.2/8.14.2) with ESMTP id n2VDXsHw048275
    2009:03:31-14:34:21 (none) exim[30834]: [12\34]  for ; Tue, 31 Mar 2009 14:34:01 +0100 (BST)
    2009:03:31-14:34:21 (none) exim[30834]: [13\34]  (envelope-from james.gillies@softek.co.uk)
    2009:03:31-14:34:21 (none) exim[30834]: [14\34] P Received: 
    2009:03:31-14:34:21 (none) exim[30834]: [15\34]  id ; Tue, 31 Mar 2009 14:33:54 +0100
    2009:03:31-14:34:21 (none) exim[30834]: [16\34]   X-CTCH-RefID: str=0001.0A0B0206.49D214E2.02A8,ss=4,sh,fgs=0
    2009:03:31-14:34:21 (none) exim[30834]: [17\34]   Content-class: urn:content-classes:message
    2009:03:31-14:34:21 (none) exim[30834]: [18\34]   MIME-Version: 1.0
    2009:03:31-14:34:21 (none) exim[30834]: [19\34]   Content-Type: multipart/alternative;
    2009:03:31-14:34:21 (none) exim[30834]: [20\34]  boundary="----_=_NextPart_001_01C9B205.55D947D3"
    2009:03:31-14:34:21 (none) exim[30834]: [21\34]   Subject: Testing 123
    2009:03:31-14:34:21 (none) exim[30834]: [22\34]   Date: Tue, 31 Mar 2009 14:33:54 +0100
    2009:03:31-14:34:21 (none) exim[30834]: [23\34] I Message-ID: 
    2009:03:31-14:34:21 (none) exim[30834]: [24\34]   X-MS-Has-Attach: 
    2009:03:31-14:34:21 (none) exim[30834]: [25\34]   X-MS-TNEF-Correlator: 
    2009:03:31-14:34:21 (none) exim[30834]: [26\34]   Thread-Topic: Testing 123
    2009:03:31-14:34:21 (none) exim[30834]: [27\34]   Thread-Index: AcmyBVXViySqoj6LQ/2rQl9q123KJw==
    2009:03:31-14:34:21 (none) exim[30834]: [28\34] F From: "James Gillies" 
    2009:03:31-14:34:21 (none) exim[30834]: [29\34] T To: 
    2009:03:31-14:34:21 (none) exim[30834]: [30\34]   X-FastNet-MailScanner-Information: 
    2009:03:31-14:34:21 (none) exim[30834]: [31\34]   X-MailScanner-ID: n2VDXsHw048275
    2009:03:31-14:34:21 (none) exim[30834]: [32\34]   X-FastNet-MailScanner: Found to be clean
    2009:03:31-14:34:21 (none) exim[30834]: [33\34]   X-FastNet-MailFilter-From: james.gillies@softek.co.uk
    2009:03:31-14:34:21 (none) exim[30834]: [34/34]   X-Spam-Status: No
    2009:03:31-14:34:21 (none) exim[30834]: 2009-03-31 14:34:21 1Loe6e-00081K-2Z SMTP connection from mailfilter7.fast.net.uk [212.42.162.167]:50841 closed by DROP in ACL
  • Dave, please submit a support request to Astaro.
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
Reply Children
  • Dave, This question was asked in a little different way on another thread, and I thought of this one.  Your Astaro correctly rejected this email because, according to the CommTouch spam qualifier, it is "confirmed" spam.  If that is not the case, then you'll need to create an exception for 'Anti-Spam checking' for *@softek.co.uk.

    Cheers - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • Hi Forum,

    just as an update: we have logged a call to Astaro three weeks ago. It looks like the "blacklists" from Commtouch have been revised in the meantime. We did not get any more rejected mails from customers during the past 3 weeks. 

    So this seems to be fixed by Commtouch. (no official information - just what I think). Perhaps this is the reason for Astaro not giving any statements to that issue here nor to the call.

    I hope in a future release the troubleshooting information of such a case will be more detailed. AND I hope there will be a way to disable any single engine to be able to work around any future hickups one of the lists shows.

    Regards, Thomas