DevHeads.net

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

Hi,

On <a href="http://www.postfix.org/postconf.5.html#smtp_tls_security_level" title="http://www.postfix.org/postconf.5.html#smtp_tls_security_level">http://www.postfix.org/postconf.5.html#smtp_tls_security_level</a>
there is a link "fingerprint", with the URL:

<a href="http://www.postfix.org/TLS_README.html#client_tls_fingerprint" title="http://www.postfix.org/TLS_README.html#client_tls_fingerprint">http://www.postfix.org/TLS_README.html#client_tls_fingerprint</a>

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

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

Hi,

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

<a href="https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=869075" title="https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=869075">https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=869075</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

Hi,

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:

From:
=?GB2312?B?tfXBoyy2/rrP0ru19cGjLMj9us/Su7X1waMsy8S6z9K7tfXBoyy3/srOtfXB?=

I wanted to reject such mail with

/^.=\?GB2312\?B\?/
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

Hi,

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 mx003.twitter.com[128.121.146.152]: 554 5.7.1 Service unavailable; Client host [128.121.146.152] blocked using bl.spamcop.net; Blocked - see <a href="http://www.spamcop.net/bl.shtml?128.121.146.152;" title="http://www.spamcop.net/bl.shtml?128.121.146.152;">http://www.spamcop.net/bl.shtml?128.121.146.152;</a> from=<twitter-follow-xxxxxxxxxx=xxxxxx. ... at postmaster dot twitter.com> to=< ... at xxxxxx dot xxx> proto=ESMTP helo=<mx003.twitter.com>

In my /etc/postfix/main.cf file, I ha