Postings by Vincent Lefevre

How to match 2a04:5200:fff4:0 in access table?

I would like to match the 2a04:5200:fff4:0 IPv6 addresses (/64 block)
in an access table (and I'd like to avoid using a cidr lookup table
for specific cases). I have

2a04:5200:fff4:0 REJECT Blacklisted

However, 2a04:5200:fff4::fe was not caught.

The access(5) man page says "The access map lookup key must be in
canonical form" but this is ambiguous as RFC 5952 does not specify
canonical form for subnetworks. For instance, if the IPv6 address
is 2a04:5200:fff4:0:1:0:0:1, then its canonical form would be
2a04:5200:fff4:0:1::1, so that the 2a04:5200:fff4:0 prefix is
necessarily valid.

bad link/anchor in the Postfix HTML documentation


On <a href="" title=""></a>
there is a link "fingerprint", with the URL:

<a href="" title=""></a>

However, on this web page, the client_tls_fingerprint anchor doesn't

postdrop hangs until reboot: warning: mail_queue_enter: create file maildrop/...: Permission denied


FYI, I've just reported the following bugs in the Debian BTS
for postfix 3.2.2:

<a href="" title=""></a>

In summary, there's one problem that is hardly reproducible,
and an incorrect error message.

When I tried to send a mail with mutt (via the usual
"/usr/sbin/sendmail -oem -oi" command), it was hanging, and ps showed
that it was due to postdrop, which was hanging. There was no such
problem when I sent a mail 20 minutes before.

mime_header_checks physical lines vs logical headers


With postfix 2.9.3-2~12.04.3 under Ubuntu:

The header_checks(5) man page says:

Note: message headers are examined one logical header at a time,
even when a message header spans multiple lines. Body lines are
always examined one line at a time.

But after doing various tests on mime_header_checks, it appears
that headers are examined one physical line at a time (instead
of logical headers).

I wonder whether this is a documentation bug or a buggy behavior
of postfix, but considering logical headers would be more useful
in practice, IMHO.

header_checks rule that doesn't work

I've received a mail having:


I wanted to reject such mail with

REJECT GB2312 in headers

in header_checks.pcre, but this didn't work. I don't understand because

postmap -q - pcre:/etc/postfix/header_checks.pcre < the_message

says that the rule applies on this line.

Any idea?

serious bug with check_client_access


It seems that I've found a serious bug in check_client_access
(or something is missing in the documentation).

A message was blocked with the following in the log:

Nov 3 21:16:55 ioooi postfix/smtpd[15423]: NOQUEUE: reject: RCPT from[]: 554 5.7.1 Service unavailable; Client host [] blocked using; Blocked - see <a href=";" title=";">;</a> from=<twitter-follow-xxxxxxxxxx=xxxxxx. ... at postmaster dot> to=< ... at xxxxxx dot xxx> proto=ESMTP helo=<>

In my /etc/postfix/ file, I ha