How to deterime the cause for rejected after DATA

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

Hi budy, have you tried adding an Exception for that Emailaddresss disabling all Tests (Spam, Virus) from the Astaro side to see whats happening?

Better yet, I had a technician call me and explain to me what the AMG does. It seems that one of the big hosting companies named Strato is labeled "high risk" for Spam and thus has been dropped.

That's fine with me and since none of our important customers uses Strato I actually haven't  installed any exceptions yet, but that would have been the way to go.

Cheers,
budy

Hi Balfson,

our astaro is currently running on version 7.306.

We do not use wan balancing.

Did astaro changed the default rbl-checklist with version 7.400 ?

sbl-xbl.spamhaus.org is´nt reachable.


regards,
Clemens

Hi,

Same problem here, today i´ve got several calls, that the senders got error messages like this

host Ip-adrress said: 550
>    Administrative prohibition (in reply to end of DATA command)
>

But the same sender later can send another e-mail to the same internal user.

In the smtp-proxy log i found, that every rejected mail lists its envelope in the log file like this one:


2009:03:24-15:27:57 IP exim[5612]: [1\38] 2009-03-24 15:27:57 1Lm7bh-0001SW-1A H=IP  F= temporarily rejected after DATA: PGSQL: query failed: ERROR:  invalid byte sequence for encoding "UTF8": 0xdc62
2009:03:24-15:27:57  exim[5612]: [2\38] Envelope-from: 
2009:03:24-15:27:57  exim[5612]: [3\38] Envelope-to: <>
2009:03:24-15:27:57  exim[5612]: [4\38] P Received:
.....

Seems to be something with rbl checks.

CU
Thomas

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

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

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