I might also suggest pdns-recursor. very fast.
Sent from my iPhone
> On Aug 8, 2022, at 4:18 PM, Demi Marie Obenour wrote:
>
> On 8/7/22 09:50, Linkcheck wrote:
>>> On 07/08/2022 1:12 pm, Rob McGee wrote:
>>> dig 2.0.0.127.zen.spamhaus.org. any
>>
>> ANY has to be after DIG, not at the end, b
On 8/7/22 09:50, Linkcheck wrote:
> On 07/08/2022 1:12 pm, Rob McGee wrote:
>> dig 2.0.0.127.zen.spamhaus.org. any
>
> ANY has to be after DIG, not at the end, but...
>
>
> ; <<>> DiG 9.10.3-P4-Ubuntu <<>> any 2.0.0.127.zen.spamhaus.org.
> ;; global options: +cmd
> ;; Got answer:
On 2022-08-08 03:09, Linkcheck wrote:
Thank you, but there never was an error in my resolver, which I
have not altered in any way.
Then the error is PEBKAC, in that you are not reading what people
have told you. Especially note the link to the Spamhaus FAQ about
query blocking and the 127.255.2
What is between Postfix and the internet:
- A load balancer?
- A firewall that inspects TCP sessions?
Question 1: were there other SMTP sessions during this time frame,
and did they have timeouts or 'unknown' commands?
The next one timed out after 306 seconds, where 300s is expected.
2022
On Mon, Aug 08, 2022 at 01:21:01PM +, White, Daniel E. (GSFC-770.0)[AEGIS]
wrote:
> 2022-08-05T17:27:37.326857+00:00 MAILRELAY postfix/smtpd[69606]: connect from
> unknown[SAME_CLIENT_IP]
> 2022-08-05T17:32:43.057669+00:00 MAILRELAY postfix/smtpd[69606]: timeout
> after CONNECT from unknown
A customer sent 6 test messages in a space of about 30 minutes.
5 out of 6 never appeared in the maillogs of 3 different relays
I am still trying to get more detail from them.
The one that did go through showed, IMHO, strange behavior:
2022-08-05T17:27:37.326857+00:00 MAILRELAY postfix/smtpd[6960
Thank you, but there never was an error in my resolver, which I have not
altered in any way. It was my own mistake in applying an incorrect dig. :(
