http://rob0.nodns4.us/postscreen.html
+1
glad to see that's still there!
it's where *I* started oh so many years ago ;-)
On 2022-08-07 08: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...
Thank you for the correction. But as you have probably discovered
by now, my syntax was correct. In fact refer to the SIMPLE USAGE
I didn't say SA / spamhaus was causing rejections, merely that I was following
up a discussion on the subject.
And I gave the relevant configs in the OP.
sounds like you're good then
o/
I didn't say SA / spamhaus was causing rejections, merely that I was
following up a discussion on the subject.
And I gave the relevant configs in the OP.
spamassassin isn't causing those rejections.
for that matter, neither is spamhaus.
something in your config is.
there are folks here that can likely assist.
unless/until your share the configs etc that've been asked for, noone's going
to guess.
On Wed, 3 Aug 2022 at 18:30, Matus UHLAR - fantomas wrote:
>
> On 03.08.22 10:39, Linkcheck wrote:
> >I have recently begun getting blocks from dbl.spamhaus.org for "valid"
> >email. I thought a single instance was an aberration but in all I've
> >seen half a dozen emails blocked - a large number
Yes. The sysytem has been working well for years and only now is failing
spamhaus tests. Until the last week or so I have never had a false
spamhaus reject of a valid email.
I have just discovered a spamassassin forum that details a similar
rejection. I am delving into that now.
My apologies. I tried dig on another OS first and that failed.
; <<>> DiG 9.16.27-Debian <<>> 2.0.0.127.zen.spamhaus.org. any
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24423
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITI
Massimo Federico Bonfigli:
> Just as a clarification, what is exactly the logic followed by Postfix here?
The logic is Garbage In, Garbage Out. Email that is not "correct"
with respect to a decades old standard cannot be delivered "correctly".
Wietse
Linkcheck:
> And now, during the past few days, zen has blocked a couple of valid
> emails, the IPs of which zen claims to know nothing about.
Are you sure that you are using a LOCAL DNS resolver
and not relying on some ISP's DNS?
Wietse
On 07/08/2022 1:12 pm, Rob McGee wrote:
dig 2.0.0.127.zen.spamhaus.org. any
On 07.08.22 14:50, Linkcheck wrote:
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:
;; ->>HEADER
You should read:
https://www.spamhaus.org/news/article/788/spamhaus-dnsbl-return-codes-technical-update.
and
https://docs.spamhaus.com/datasets/docs/source/40-real-world-usage/PublicMirrors/MTAs/020-Postfix.html
+1
and,
https://www.google.com/search?q=spamhaus+postfix+zen
-> first four link
On Sun, 7 Aug 2022, Linkcheck wrote:
And now, during the past few days, zen has blocked a couple of valid emails,
the IPs of which zen claims to know nothing about.
Last week zen.spamhaus blocked over 280 emails; I've going to miss it.
I have now removed spamhaus from postfix entirely and hop
Hi,
thank you for clearing up the pflogsumm status.
>seems that two forks are a bit ahead
>https://github.com/sbidy/pflogsumm
>https://github.com/rebouny/pflogsumm
I tried the newer version from the debian repository and the forks above.
The one from sbidy reports the cleanup header part again.
ANY has to be after DIG, not at the end, but...
dig 2.0.0.127.zen.spamhaus.org. any
; <<>> DiG 9.16.30-RH <<>> 2.0.0.127.zen.spamhaus.org. any
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16710
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0,
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:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, i
On 2022-08-07 06:08, PGNet Dev wrote:
For reference, a couple of samples of the blocked emails are:
NOQUEUE: reject: RCPT from o4.email.wetransfer.com[192.254.123.89]:
554 5.7.1 Service
I would add to the useful information below that neither sample is in
fact listed in Zen at this time.
YOU
On 07.08.22 10:42, ludi cree wrote:
on a new server with debian buster and Plesk some lines of the postfix log
are not reported by pflogsumm anymore.
pflogsumm is not developed by postfix people.
unfortunately, it's not developed for some time by original author
(http://jimsun.linxnet.com/pos
Just as a clarification, what is exactly the logic followed by Postfix here?
When accepting an email postfix accepts any line length, then when
delivering if a line is longer than 1000 (CRLF included) it breaks it
adding a CRLF and "hoping" nothing gets messed up in the process?
Or is there some
For reference, a couple of samples of the blocked emails are:
NOQUEUE: reject: RCPT from o4.email.wetransfer.com[192.254.123.89]: 554 5.7.1 Service
unavailable; Client host [192.254.123.89] blocked using zen.spamhaus.org;
from= to=<(redacted)>
proto=ESMTP helo=
Zen list is an amalgam of X
And now, during the past few days, zen has blocked a couple of valid
emails, the IPs of which zen claims to know nothing about.
Last week zen.spamhaus blocked over 280 emails; I've going to miss it.
I have now removed spamhaus from postfix entirely and hope that
spamassassin will catch any nas
Hi,
on a new server with debian buster and Plesk some lines of the postfix log
are not reported by pflogsumm anymore.
The lines look like:
Aug 6 15:45:07 mx10 postfix/cleanup[0]: D8B0A1480AA4: reject: header
Reply-To: nigerias...@gmail.com from
mail-ed1-x532.google.com[2a00:1450:4864:20::53
22 matches
Mail list logo
