Robert Schetterer wrote the following on 3/4/2013 12:37 PM:
> Am 04.03.2013 19:31, schrieb Blake Hudson:
>> OK, so we ask for a PTR on 212.0.171.63.in-addr.arpa and instead receive
>> a CNAME (with additional). Did anyone notice that the CNAME does not
>> resolve?
> yeah ,my dns cache didnt resolved it
> had to be reloaded
>
>
> Best Regards
> MfG Robert Schetterer
>
Robert, you show the same problem as me (different version of bind
9.8.x). Seems to be a bind 9.8 specific behavior to return SERVFAIL on
this lookup. FWIW, Bind 9.2.x uses the additional info in the first
query results without performing any lookup/validation on the CNAME
(63.171.0.212.cust.lkq.sprintlink.net).

flushing cache or restarting bind does not resolve the issue. Unless you
can show me otherwise...

On Mon, Mar 04, 2013 at 12:31:08PM -0600, Blake Hudson wrote:
> KSB wrote the following on 3/4/2013 12:13 PM:
> >On 2013.03.04. 20:06, Blake Hudson wrote:
> >>Just hoping to get a consensus on this. Postfix is stating that a
> >>host (in fact several hosts from the same ISP) does not have
> >>rDNS, because our DNS (Bind 9.8) returns SERVFAIL when looking up
> >>a PTR record for it. The IP in question is 63.171.0.212. From my

See RFC 2317.

> >>perspective, this IP does not have a PTR record and as such does
> >>not have proper rDNS. Other tools (including older versions of
> >>bind) might say otherwise; What do you say?
> >>*
> >Seems very, very strage... but probably this is allowed, anybody knows?
> >
> >;; QUESTION SECTION:
> >;212.0.171.63.in-addr.arpa.     IN      PTR
> >
> >;; ANSWER SECTION:
> >212.0.171.63.in-addr.arpa. 86400 IN     CNAME
> >63.171.0.212.cust.lkq.sprintlink.net.
> >63.171.0.212.cust.lkq.sprintlink.net. 86400 IN PTR mail1.lkqcorp.com.

It's fine. As to why your named is returning SERVFAIL, that is
another issue. Obviously a SERVFAIL will prevent it from being
resolved. I get the SERVFAIL as well:

Mar  4 12:51:36 chestnut named[1811]: error (chase DS servers)
resolving 'cust.lkq.sprintlink.net/DS/IN': 144.228.254.10#53
Mar  4 12:51:36 chestnut named[1811]: error (insecurity proof failed)
resolving 'lkq.sprintlink.net/NS/IN': 144.228.255.10#53
Mar  4 12:51:36 chestnut named[1811]: error (insecurity proof failed)
resolving 'lkq.sprintlink.net/NS/IN': 206.228.179.10#53
Mar  4 12:51:36 chestnut named[1811]: error (insecurity proof failed)
resolving 'lkq.sprintlink.net/NS/IN': 144.228.254.10#53
Mar  4 12:51:36 chestnut named[1811]: error (no valid DS) resolving
'63.171.0.212.cust.lkq.sprintlink.net/PTR/IN': 144.228.254.10#53

This is a problem with the DNSSEC signing.

> OK, so we ask for a PTR on 212.0.171.63.in-addr.arpa and instead
> receive a CNAME (with additional). Did anyone notice that the CNAME
> does not resolve?
>
> --
>
> # dig @ns1-auth.sprintlink.net 63.171.0.212.cust.lkq.sprintlink.net

You're doing a default query type, for "A".

> ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.10.rc1.el6_3.4 <<>>
> @ns1-auth.sprintlink.net 63.171.0.212.cust.lkq.sprintlink.net
> ; (2 servers found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7207

NOERROR means that the name exists, but there is no data of the
requested type, A. It's wrong to assume that all names in the DNS
should have A records.

> ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
> ;; WARNING: recursion requested but not available
>
> ;; QUESTION SECTION:
> ;63.171.0.212.cust.lkq.sprintlink.net. IN A
>
> ;; AUTHORITY SECTION:
> cust.lkq.sprintlink.net. 7200   IN      SOA ns1-auth.sprintlink.net.
> dns-admin.sprint.net. 2010080301 43200 3600 2419200 7200
>
> ;; Query time: 50 msec
> ;; SERVER: 206.228.179.10#53(206.228.179.10)
> ;; WHEN: Mon Mar  4 12:04:25 2013
> ;; MSG SIZE  rcvd: 116
>
> --

--
   http://rob0.nodns4.us/ -- system administration and consulting
   Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:

Am 04.03.2013 19:06, schrieb Blake Hudson:
> Just hoping to get a consensus on this. Postfix is stating that a host (in
fact several hosts from the same ISP)
> does not have rDNS, because our DNS (Bind 9.8) returns SERVFAIL when looking
up a PTR record for it. The IP in
> question is 63.171.0.212. From my perspective, this IP does not have a PTR
record and as such does not have proper
> rDNS. Other tools (including older versions of bind) might say otherwise; What
do you say?

that a CNAME here is very strange and this setup is not sane

[harry@srv-rhsoft:~]$ nslookup 63.171.0.212
Server:         127.0.0.1
Address:        127.0.0.1#53

Non-authoritative answer:
212.0.171.63.in-addr.arpa       canonical name =
63.171.0.212.cust.lkq.sprintlink.net.
63.171.0.212.cust.lkq.sprintlink.net    name = mail1.lkqcorp.com.

Hello,

For a lab test, with several computers sending mail to any domain, I
would like to setup a postfix server accepting and storing locally to
only one account any mail received. It would be a sort of blackhole
relay server, but with mail kept locally, no mail going out from it.

Any idea on how to configure postfix this way?

Thanks,
--
Nicolas

Am 04.03.2013 19:46, schrieb Blake Hudson:
>
> Robert Schetterer wrote the following on 3/4/2013 12:37 PM:
>> Am 04.03.2013 19:31, schrieb Blake Hudson:
>>> OK, so we ask for a PTR on 212.0.171.63.in-addr.arpa and instead receive
>>> a CNAME (with additional). Did anyone notice that the CNAME does not
>>> resolve?
>> yeah ,my dns cache didnt resolved it
>> had to be reloaded
>>
>>
>> Best Regards
>> MfG Robert Schetterer
>>
> Robert, you show the same problem as me (different version of bind
> 9.8.x). Seems to be a bind 9.8 specific behavior to return SERVFAIL on
> this lookup. FWIW, Bind 9.2.x uses the additional info in the first
> query results without performing any lookup/validation on the CNAME
> (63.171.0.212.cust.lkq.sprintlink.net).
>
> flushing cache or restarting bind does not resolve the issue. Unless you
> can show me otherwise...

its by dnssec-validation auto in  BIND 9.8.1-P1

/usr/sbin/named -v
BIND 9.8.1-P1

dig @localhost -x 63.171.0.212

; <<>> DiG 9.8.1-P1 <<>> @localhost -x 63.171.0.212
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 38497
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;212.0.171.63.in-addr.arpa.     IN      PTR

;; Query time: 3462 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Mar  4 20:01:51 2013
;; MSG SIZE  rcvd: 43


deconfigure or comment out

dnssec-validation auto


etc/init.d/bind9 restart
  * Stopping domain name service... bind9

                                     waiting for pid 28122 to die


                              [ OK ]
  * Starting domain name service... bind9

                              [ OK ]
root@newlinux:~# dig @localhost -x 63.171.0.212

; <<>> DiG 9.8.1-P1 <<>> @localhost -x 63.171.0.212
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47133
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 6

;; QUESTION SECTION:
;212.0.171.63.in-addr.arpa.     IN      PTR

;; ANSWER SECTION:
212.0.171.63.in-addr.arpa. 86400 IN     CNAME
63.171.0.212.cust.lkq.sprintlink.net.
63.171.0.212.cust.lkq.sprintlink.net. 86400 IN PTR mail1.lkqcorp.com.

;; AUTHORITY SECTION:
cust.lkq.sprintlink.net. 86400  IN      NS      ns1-auth.sprintlink.net.
cust.lkq.sprintlink.net. 86400  IN      NS      ns3-auth.sprintlink.net.
cust.lkq.sprintlink.net. 86400  IN      NS      ns2-auth.sprintlink.net.

;; ADDITIONAL SECTION:
ns1-auth.sprintlink.net. 86399  IN      A       206.228.179.10
ns1-auth.sprintlink.net. 86399  IN      AAAA    2600::a1
ns2-auth.sprintlink.net. 86399  IN      A       144.228.254.10
ns2-auth.sprintlink.net. 86399  IN      AAAA    2600::a2
ns3-auth.sprintlink.net. 86399  IN      A       144.228.255.10
ns3-auth.sprintlink.net. 86399  IN      AAAA    2600::a3


compared

/usr/sbin/named -v
BIND 9.7.6-P4

dig @localhost -x 63.171.0.212

; <<>> DiG 9.7.6-P4 <<>> @localhost -x 63.171.0.212
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26972
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 6

;; QUESTION SECTION:
;212.0.171.63.in-addr.arpa.     IN      PTR

;; ANSWER SECTION:
212.0.171.63.in-addr.arpa. 85099 IN     CNAME
63.171.0.212.cust.lkq.sprintlink.net.
63.171.0.212.cust.lkq.sprintlink.net. 85099 IN PTR mail1.lkqcorp.com.


try post bind list for details


Best Regards
MfG Robert Schetterer

--
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Franziskanerstraße 15, 81669 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer
Aufsichtsratsvorsitzender: Joerg Heidrich

/dev/rob0 wrote the following on 3/4/2013 12:56 PM:
> On Mon, Mar 04, 2013 at 12:31:08PM -0600, Blake Hudson wrote:
>> KSB wrote the following on 3/4/2013 12:13 PM:
>>> On 2013.03.04. 20:06, Blake Hudson wrote:
>>>> Just hoping to get a consensus on this. Postfix is stating that a
>>>> host (in fact several hosts from the same ISP) does not have
>>>> rDNS, because our DNS (Bind 9.8) returns SERVFAIL when looking up
>>>> a PTR record for it. The IP in question is 63.171.0.212. From my
> See RFC 2317.
>
>>>> perspective, this IP does not have a PTR record and as such does
>>>> not have proper rDNS. Other tools (including older versions of
>>>> bind) might say otherwise; What do you say?
>>>> *
>>> Seems very, very strage... but probably this is allowed, anybody knows?
>>>
>>> ;; QUESTION SECTION:
>>> ;212.0.171.63.in-addr.arpa.     IN      PTR
>>>
>>> ;; ANSWER SECTION:
>>> 212.0.171.63.in-addr.arpa. 86400 IN     CNAME
>>> 63.171.0.212.cust.lkq.sprintlink.net.
>>> 63.171.0.212.cust.lkq.sprintlink.net. 86400 IN PTR mail1.lkqcorp.com.
> It's fine. As to why your named is returning SERVFAIL, that is
> another issue. Obviously a SERVFAIL will prevent it from being
> resolved. I get the SERVFAIL as well:
>
> Mar  4 12:51:36 chestnut named[1811]: error (chase DS servers)
> resolving 'cust.lkq.sprintlink.net/DS/IN': 144.228.254.10#53
> Mar  4 12:51:36 chestnut named[1811]: error (insecurity proof failed)
> resolving 'lkq.sprintlink.net/NS/IN': 144.228.255.10#53
> Mar  4 12:51:36 chestnut named[1811]: error (insecurity proof failed)
> resolving 'lkq.sprintlink.net/NS/IN': 206.228.179.10#53
> Mar  4 12:51:36 chestnut named[1811]: error (insecurity proof failed)
> resolving 'lkq.sprintlink.net/NS/IN': 144.228.254.10#53
> Mar  4 12:51:36 chestnut named[1811]: error (no valid DS) resolving
> '63.171.0.212.cust.lkq.sprintlink.net/PTR/IN': 144.228.254.10#53
>
> This is a problem with the DNSSEC signing.
>
>> OK, so we ask for a PTR on 212.0.171.63.in-addr.arpa and instead
>> receive a CNAME (with additional). Did anyone notice that the CNAME
>> does not resolve?
>>
>> --
>>
>> # dig @ns1-auth.sprintlink.net 63.171.0.212.cust.lkq.sprintlink.net
> You're doing a default query type, for "A".
>
>> ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.10.rc1.el6_3.4 <<>>
>> @ns1-auth.sprintlink.net 63.171.0.212.cust.lkq.sprintlink.net
>> ; (2 servers found)
>> ;; global options: +cmd
>> ;; Got answer:
>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7207
> NOERROR means that the name exists, but there is no data of the
> requested type, A. It's wrong to assume that all names in the DNS
> should have A records.
>
>> ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
>> ;; WARNING: recursion requested but not available
>>
>> ;; QUESTION SECTION:
>> ;63.171.0.212.cust.lkq.sprintlink.net. IN A
>>
>> ;; AUTHORITY SECTION:
>> cust.lkq.sprintlink.net. 7200   IN      SOA ns1-auth.sprintlink.net.
>> dns-admin.sprint.net. 2010080301 43200 3600 2419200 7200
>>
>> ;; Query time: 50 msec
>> ;; SERVER: 206.228.179.10#53(206.228.179.10)
>> ;; WHEN: Mon Mar  4 12:04:25 2013
>> ;; MSG SIZE  rcvd: 116
>>
>> --


Awesome answer. Thanks for your expertise!

I had been reading RFC 1035 and was simply unsure of what, exactly, was
allowed and what was not - Sometimes RFCs allow for interpretation
differences between readers. I'll need to read 2317 again.

You're absolutely correct about it being wrong to assume that all
records are A. Maybe I am complacent in my expectation that I can ask
for an A record and receive a CNAME in return, but what else would/could
one expect - isn't this the behavior of CNAMEs? If I perform the
following query I do get an answer in return:

--
# dig @ns1-auth.sprintlink.net ANY 63.171.0.212.cust.lkq.sprintlink.net

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.10.rc1.el6_3.6 <<>>
@ns1-auth.sprintlink.net ANY 63.171.0.212.cust.lkq.sprintlink.net
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8377
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;63.171.0.212.cust.lkq.sprintlink.net. IN ANY

;; ANSWER SECTION:
63.171.0.212.cust.lkq.sprintlink.net. 86400 IN PTR mail1.lkqcorp.com.

;; AUTHORITY SECTION:
cust.lkq.sprintlink.net. 86400  IN      NS ns1-auth.sprintlink.net.
cust.lkq.sprintlink.net. 86400  IN      NS ns2-auth.sprintlink.net.
cust.lkq.sprintlink.net. 86400  IN      NS ns3-auth.sprintlink.net.

;; Query time: 48 msec
;; SERVER: 206.228.179.10#53(206.228.179.10)
;; WHEN: Mon Mar  4 13:08:25 2013
;; MSG SIZE  rcvd: 154
--

I still am unsure if it's valid to ask for a PTR record and receive a
CNAME in return. If it is, I assume that CNAME needs to lead to a valid
PTR record at some point.

Thanks for pointing out the DNSSEC error. I was focusing on the unusual
PTR setup (in my experience) and didn't even consider DNSSEC. Looks like
Sprint has a DNS issue to resolve.

Thanks,
--Blake

On Mon, Mar 04, 2013 at 08:02:30PM +0100, Nicolas KOWALSKI wrote:
> For a lab test, with several computers sending mail to any domain,
> I would like to setup a postfix server accepting and storing
> locally to only one account any mail received. It would be a sort
> of blackhole relay server, but with mail kept locally, no mail
> going out from it.
>
> Any idea on how to configure postfix this way?

I've answered this before. One link that I found (interestingly,
through a search for "postfix blackhole") is here:

http://archives.neohapsis.com/archives/postfix/2010-04/0168.html
--
   http://rob0.nodns4.us/ -- system administration and consulting
   Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:

On 3/4/2013 1:02 PM, Nicolas KOWALSKI wrote:
> Hello,
>
> For a lab test, with several computers sending mail to any domain, I
> would like to setup a postfix server accepting and storing locally to
> only one account any mail received. It would be a sort of blackhole
> relay server, but with mail kept locally, no mail going out from it.
>
> Any idea on how to configure postfix this way?
>
> Thanks,
>


There's several ways to do this.  I think the easiest is:

# main.cf
header_checks = regexp:/etc/postfix/header_checks

in your header_checks file:
/./  REDIRECT someone@...


where "someone" is a valid local user, and "example.com" is listed
in mydestination.




   -- Noel Jones

On Mon, Mar 04, 2013 at 01:22:39PM -0600, Blake Hudson wrote:
> I still am unsure if it's valid to ask for a PTR record and receive
> a CNAME in return. If it is, I assume that CNAME needs to lead to a
> valid PTR record at some point.

The way it works: when you query for any type and get a CNAME, the
resolver (dig in this case) looks up that type record for the CNAME
target.

> Thanks for pointing out the DNSSEC error. I was focusing on the
> unusual PTR setup (in my experience) and didn't even consider
> DNSSEC. Looks like Sprint has a DNS issue to resolve.

Yes, this would all be fine if the DNSSEC was right, or with the
"workaround" as proposed upthread, to disable DNSSEC checking in your
named. (I would not recommend that, but indeed, it's a possible way
to shift the error from Sprint to yourself.)
--
   http://rob0.nodns4.us/ -- system administration and consulting
   Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:

Le 04/03/2013 20:35, Noel Jones a écrit :
> On 3/4/2013 1:02 PM, Nicolas KOWALSKI wrote:
>> Hello,
>>
>> For a lab test, with several computers sending mail to any domain, I
>> would like to setup a postfix server accepting and storing locally to
>> only one account any mail received. It would be a sort of blackhole
>> relay server, but with mail kept locally, no mail going out from it.
>>
>> Any idea on how to configure postfix this way?
>>
>> Thanks,
>>
>
> There's several ways to do this.  I think the easiest is:
>
> # main.cf
> header_checks = regexp:/etc/postfix/header_checks
>
> in your header_checks file:
> /./  REDIRECT someone@...
>
>
> where "someone" is a valid local user, and "example.com" is listed
> in mydestination.
>
>
>
>
>    -- Noel Jones
>

I think always_bcc would be a better solution, it does not involve
trying to match anything, it justs sends a copy to the specified address.

Robert Schetterer wrote the following on 3/4/2013 1:08 PM:
> Am 04.03.2013 19:46, schrieb Blake Hudson:
>> Robert Schetterer wrote the following on 3/4/2013 12:37 PM:
>>> Am 04.03.2013 19:31, schrieb Blake Hudson:
>>>> OK, so we ask for a PTR on 212.0.171.63.in-addr.arpa and instead receive
>>>> a CNAME (with additional). Did anyone notice that the CNAME does not
>>>> resolve?
>>> yeah ,my dns cache didnt resolved it
>>> had to be reloaded
>>>
>>>
>>> Best Regards
>>> MfG Robert Schetterer
>>>
>> Robert, you show the same problem as me (different version of bind
>> 9.8.x). Seems to be a bind 9.8 specific behavior to return SERVFAIL on
>> this lookup. FWIW, Bind 9.2.x uses the additional info in the first
>> query results without performing any lookup/validation on the CNAME
>> (63.171.0.212.cust.lkq.sprintlink.net).
>>
>> flushing cache or restarting bind does not resolve the issue. Unless you
>> can show me otherwise...
> its by dnssec-validation auto in  BIND 9.8.1-P1
>
> /usr/sbin/named -v
> BIND 9.8.1-P1
>
> dig @localhost -x 63.171.0.212
>
> ; <<>> DiG 9.8.1-P1 <<>> @localhost -x 63.171.0.212
> ; (1 server found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 38497
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
>
> ;; QUESTION SECTION:
> ;212.0.171.63.in-addr.arpa.     IN      PTR
>
> ;; Query time: 3462 msec
> ;; SERVER: 127.0.0.1#53(127.0.0.1)
> ;; WHEN: Mon Mar  4 20:01:51 2013
> ;; MSG SIZE  rcvd: 43
>
>
> deconfigure or comment out
>
> dnssec-validation auto
>
>
> etc/init.d/bind9 restart
>   * Stopping domain name service... bind9
>
>                                      waiting for pid 28122 to die
>
>
>                               [ OK ]
>   * Starting domain name service... bind9
>
>                               [ OK ]
> root@newlinux:~# dig @localhost -x 63.171.0.212
>
> ; <<>> DiG 9.8.1-P1 <<>> @localhost -x 63.171.0.212
> ; (1 server found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47133
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 6
>
> ;; QUESTION SECTION:
> ;212.0.171.63.in-addr.arpa.     IN      PTR
>
> ;; ANSWER SECTION:
> 212.0.171.63.in-addr.arpa. 86400 IN     CNAME
> 63.171.0.212.cust.lkq.sprintlink.net.
> 63.171.0.212.cust.lkq.sprintlink.net. 86400 IN PTR mail1.lkqcorp.com.
>
> ;; AUTHORITY SECTION:
> cust.lkq.sprintlink.net. 86400  IN      NS      ns1-auth.sprintlink.net.
> cust.lkq.sprintlink.net. 86400  IN      NS      ns3-auth.sprintlink.net.
> cust.lkq.sprintlink.net. 86400  IN      NS      ns2-auth.sprintlink.net.
>
> ;; ADDITIONAL SECTION:
> ns1-auth.sprintlink.net. 86399  IN      A       206.228.179.10
> ns1-auth.sprintlink.net. 86399  IN      AAAA    2600::a1
> ns2-auth.sprintlink.net. 86399  IN      A       144.228.254.10
> ns2-auth.sprintlink.net. 86399  IN      AAAA    2600::a2
> ns3-auth.sprintlink.net. 86399  IN      A       144.228.255.10
> ns3-auth.sprintlink.net. 86399  IN      AAAA    2600::a3
>
>
> compared
>
> /usr/sbin/named -v
> BIND 9.7.6-P4
>
> dig @localhost -x 63.171.0.212
>
> ; <<>> DiG 9.7.6-P4 <<>> @localhost -x 63.171.0.212
> ; (1 server found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26972
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 6
>
> ;; QUESTION SECTION:
> ;212.0.171.63.in-addr.arpa.     IN      PTR
>
> ;; ANSWER SECTION:
> 212.0.171.63.in-addr.arpa. 85099 IN     CNAME
> 63.171.0.212.cust.lkq.sprintlink.net.
> 63.171.0.212.cust.lkq.sprintlink.net. 85099 IN PTR mail1.lkqcorp.com.
>
>
> try post bind list for details
>
>
> Best Regards
> MfG Robert Schetterer
>
# dig @8.8.8.8 PTR 63.171.0.212.cust.lkq.sprintlink.net +dnssec

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.10.rc1.el6_3.6 <<>> @8.8.8.8 PTR
63.171.0.212.cust.lkq.sprintlink.net +dnssec
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 27767
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 512
;; QUESTION SECTION:
;63.171.0.212.cust.lkq.sprintlink.net. IN PTR

;; Query time: 441 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Mon Mar  4 13:44:03 2013
;; MSG SIZE  rcvd: 65



# dig @8.8.8.8 PTR 63.171.0.212.cust.lkq.sprintlink.net +nodnssec

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.10.rc1.el6_3.6 <<>> @8.8.8.8 PTR
63.171.0.212.cust.lkq.sprintlink.net +nodnssec
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14054
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;63.171.0.212.cust.lkq.sprintlink.net. IN PTR

;; ANSWER SECTION:
63.171.0.212.cust.lkq.sprintlink.net. 390 IN PTR mail1.lkqcorp.com.

;; Query time: 19 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Mon Mar  4 13:44:09 2013
;; MSG SIZE  rcvd: 85


If Sprint has setup DNSSEC on their zones incorrectly, I would rather
they resolve the issue they've created rather than turning of DNSSEC
validation on my server (which I've intentionally enabled). I don't
think posting to the bind list or any other action on my part is
necessary at this point. Thanks for the recommendations and the pointer,
as well as another set of eyes; It was helpful to have a point of
reference from multiple people running different software in different
configurations.

On 3/4/2013 1:42 PM, Erwan David wrote:
> Le 04/03/2013 20:35, Noel Jones a écrit :
>> On 3/4/2013 1:02 PM, Nicolas KOWALSKI wrote:
>>> Hello,
>>>
>>> For a lab test, with several computers sending mail to any domain, I
>>> would like to setup a postfix server accepting and storing
>>> locally to
>>> only one account any mail received. It would be a sort of blackhole
>>> relay server, but with mail kept locally, no mail going out from it.
>>>
>>> Any idea on how to configure postfix this way?
>>>
>>> Thanks,
>>>
>>
>> There's several ways to do this.  I think the easiest is:
>>
>> # main.cf
>> header_checks = regexp:/etc/postfix/header_checks
>>
>> in your header_checks file:
>> /./  REDIRECT someone@...
>>
>>
>> where "someone" is a valid local user, and "example.com" is listed
>> in mydestination.
>>
>>
>>
>>
>>    -- Noel Jones
>>
>
> I think always_bcc would be a better solution, it does not involve
> trying to match anything, it justs sends a copy to the specified
> address.


The goal stated is to not allow mail to escape the lab, eg. a
blackhole.  always_bcc does not meet that requirement.



   -- Noel Jones

On 4 Mar 2013, at 14:22, Blake Hudson wrote:

> Maybe I am complacent in my expectation that I can ask for an A record
> and receive a CNAME in return, but what else would/could one expect -
> isn't this the behavior of CNAMEs?

No. A CNAME record provides the canonical name that should be used
instead of the name originally queried. It applies to all record types,
so in the event that a query returns a CNAME record without additional
records with the canonical name as the label and the requested record
type, the next step for the originator of the query is to make a query
for the same record type using the canonical name as the label instead
of the original name. If a CNAME record exists for a particular name, it
is used  as the answer to queries for any record type at that name other
than NSEC and RRSIG.

Hi

After years of a smoothly running mail server, my logs are starting to
fill with this error message:
fatal: proxy:mysql:/etc/postfix/mailalias.cf(0,lock|fold_fix): table
lookup problem


I haven't updated anything or changed any configs (in either mysql or
postfix) so I'd appreciate some hints as to how to track this down?

According to mysql postfix is behaving properly (as you'd expect).

+------+---------+-----------+-------+---------+------+-------+-----------------\
-+
| Id   | User    | Host      | db    | Command | Time | State | Info          |
+------+---------+-----------+-------+---------+------+-------+-----------------\
-+
|  379 | postfix | localhost | Mail  | Sleep   |   25 |       | NULL
           |


So I'm not sure why it thinks there is a lock.  I found one stub that
suggested this happened with the mysql.sock was not in the chroot
jail.  But as I said, it's been running flawlessly for years, so I
don't forsee that as the issue.

Nevertheless, here's my postconf -n

access_map_reject_code = 550
alias_database = hash:/etc/postfix/aliases
alias_maps = $alias_database
allow_untrusted_routing = no
append_dot_mydomain = no
biff = no
body_checks_size_limit = 51200
bounce_size_limit = 50000
broken_sasl_auth_clients = yes
command_directory = /usr/sbin
config_directory = /etc/postfix
content_filter = smtp-amavis:[127.0.0.1]:10024
daemon_directory = /usr/lib/postfix
debug_peer_level = 1
default_destination_concurrency_limit = 25
disable_vrfy_command = yes
fast_flush_domains = $relay_domains
header_checks = regexp:/etc/postfix/header_checks
header_size_limit = 102400
home_mailbox = Maildir/
inet_interfaces = all
invalid_hostname_reject_code = 501
local_destination_concurrency_limit = 2
local_recipient_maps = proxy:unix:passwd.byname $virtual_alias_maps $alias_maps
mail_spool_directory = /var/spool/mail
mailbox_command = procmail -a "$EXTENSION"
mailbox_size_limit = 5120000000
message_size_limit = 20480000
mydestination =
mydomain = perlphreak.net
myhostname = mail.perphreak.net
mynetworks = 127.0.0.0/8
mynetworks_style = host
myorigin = $mydomain
recipient_delimiter = -
reject_code = 550
relay_domains = /etc/postfix/mxbackups
relay_domains_reject_code = 550
relayhost =
smtp_tls_CAfile = /etc/ssl/keys/perlphreak-ca.crt
smtp_tls_cert_file = /etc/ssl/keys/mail.perlphreak.net.crt
smtp_tls_key_file = /etc/ssl/private/mail.perlphreak.net.key
smtp_tls_loglevel = 1
smtp_tls_note_starttls_offer = yes
smtp_tls_security_level = may
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtp_tls_session_cache_timeout = 3600s
smtpd_banner = $myhostname ESMTP $mail_name ($mail_version) (Debian/GNU)
smtpd_data_restrictions = sleep 1,      reject_unauth_pipelining,       permit
smtpd_delay_reject = yes
smtpd_helo_required = yes
smtpd_recipient_limit = 250
smtpd_recipient_restrictions = reject_non_fqdn_sender,
reject_non_fqdn_recipient,    permit_sasl_authenticated,
reject_sender_login_mismatch,
reject_authenticated_sender_login_mismatch,     check_helo_access
hash:/etc/postfix/helo_checks,        reject_invalid_helo_hostname,
reject_non_fqdn_helo_hostname,  reject_unknown_helo_hostname,
reject_unknown_sender_domain,   reject_unknown_recipient_domain,
permit_mynetworks,  reject_unauth_destination,
reject_unlisted_recipient,      check_recipient_access
mysql:/etc/postfix/Mail-Disabled.cf,     check_helo_access
hash:/etc/postfix/helo_checks,        check_recipient_access
hash:/etc/postfix/laxdomains,    check_client_access
hash:/etc/postfix/ip_whitelist,     check_sender_access
hash:/etc/postfix/backscatter
check_reverse_client_hostname_access pcre:/etc/postfix/fqrdns.pcre,
  check_policy_service unix:private/policy-spf,   check_policy_service
inet:127.0.0.1:10031,      reject_rbl_client bl.spamcop.net,
reject_rbl_client zen.spamhaus.org, permit
smtpd_sasl_auth_enable = yes
smtpd_sasl_local_domain = perlphreak.net
smtpd_sasl_path = private/auth
smtpd_sasl_security_options = noanonymous
smtpd_sasl_tls_security_options = $smtpd_sasl_security_options
smtpd_sasl_type = dovecot
smtpd_timeout = 300s
smtpd_tls_CAfile = /etc/ssl/keys/perlphreak-ca.crt
smtpd_tls_auth_only = no
smtpd_tls_cert_file = /etc/ssl/keys/mail.perlphreak.net.crt
smtpd_tls_key_file = /etc/ssl/private/mail.perlphreak.net.key
smtpd_tls_loglevel = 1
smtpd_tls_received_header = yes
smtpd_tls_security_level = may
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtpd_tls_session_cache_timeout = 3600s
strict_rfc821_envelopes = yes
tls_random_source = dev:/dev/urandom
unknown_address_reject_code = 554
unknown_client_reject_code = 554
unknown_hostname_reject_code = 554
unknown_local_recipient_reject_code = 554
virtual_alias_maps = hash:/etc/postfix/virtual_user_aliases,
proxy:mysql:/etc/postfix/mailalias.cf
virtual_gid_maps = static:115
virtual_mailbox_base = /var/spool/mail/virtual
virtual_mailbox_domains = proxy:mysql:/etc/postfix/maildomain.cf
virtual_mailbox_limit = 5000000000
virtual_mailbox_limit_inbox = no
virtual_mailbox_limit_maps = mysql:/etc/postfix/Mail-Quota.cf
virtual_mailbox_limit_override = yes
virtual_mailbox_maps = mysql:/etc/postfix/Mail-Mailbox.cf
virtual_maildir_extended = yes
virtual_maildir_limit_message = "User over quota, try again later"
virtual_minimum_uid = 108
virtual_overquota_bounce = yes
virtual_transport = dovecot
virtual_uid_maps = static:108

The relevant lines from master.cf

# ==========================================================================
# service type  private unpriv  chroot  wakeup  maxproc command + args
#               (yes)   (yes)   (yes)   (never) (100)
# ==========================================================================
smtp      inet  n       -       -       -       -       smtpd -v
submission inet n       -       n       -       -       smtpd
    -o syslog_name=postfix/submission
    -o smtpd_delay_reject=yes
    -o receive_override_options=no_address_mappings
    -o always_add_missing_headers=yes
    -o content_filter=dksign:[127.0.0.1]:10028
    -o smtpd_enforce_tls=yes
    -o smtpd_sasl_auth_enable=yes
    -o smtpd_tls_security_level=encrypt
    -o smtpd_tls_auth_only=yes
    -o
smtpd_recipient_restrictions=reject_non_fqdn_sender,reject_non_fqdn_recipient,pe\
rmit_sasl_authenticated,reject


Should submission be chrooted?  I can't see why it would need to be if
smtp isn't.  It is working, but I'm happy to change it if that's the
issue.

Thanks

Simon

Simon Brereton:
> Hi
>
> After years of a smoothly running mail server, my logs are starting to
> fill with this error message:
> fatal: proxy:mysql:/etc/postfix/mailalias.cf(0,lock|fold_fix): table
> lookup problem

I would expcet to see some warning before an uninformative "fatal" message.
BTW the "(0,lock|fold_fix)" are Postfix-internal flags. It does not mean
that there is a problem locking mysql. the lock would be used with
files such as Berkeley DB.

		 Wietse

On 5 March 2013 16:47, Wietse Venema <wietse@...> wrote:
> Simon Brereton:
>> Hi
>>
>> After years of a smoothly running mail server, my logs are starting to
>> fill with this error message:
>> fatal: proxy:mysql:/etc/postfix/mailalias.cf(0,lock|fold_fix): table
>> lookup problem
>
> I would expcet to see some warning before an uninformative "fatal" message.
> BTW the "(0,lock|fold_fix)" are Postfix-internal flags. It does not mean
> that there is a problem locking mysql. the lock would be used with
> files such as Berkeley DB.
>
>                 Wietse

Yes, I suppose there would be!  I found two different types.

Mar  5 08:45:12 mail postfix/smtpd[24830]: connect from unknown[117.6.222.107]
Mar  5 08:45:14 mail postfix/proxymap[24831]: warning: mysql query
failed: MySQL server has gone away
Mar  5 08:45:14 mail postfix/trivial-rewrite[24833]: fatal:
proxy:mysql:/etc/postfix/mailalias.cf(0,lock|fold_fix): table lookup
problem
Mar  5 08:45:15 mail postfix/master[4283]: warning: process
/usr/lib/postfix/trivial-rewrite pid 24833 exit status 1
Mar  5 08:45:16 mail postfix/trivial-rewrite[24854]: fatal:
proxy:mysql:/etc/postfix/mailalias.cf(0,lock|fold_fix): table lookup
problem
Mar  5 08:45:17 mail postfix/smtpd[24830]: warning: problem talking to
service rewrite: Success
Mar  5 08:45:17 mail postfix/master[4283]: warning: process
/usr/lib/postfix/trivial-rewrite pid 24854 exit status 1
Mar  5 08:45:17 mail postfix/master[4283]: warning:
/usr/lib/postfix/trivial-rewrite: bad command startup -- throttling

and

Mar  5 10:53:21 mail postfix/smtpd[29350]: connect from unknown[81.213.239.67]
Mar  5 10:53:22 mail postfix/proxymap[26043]: warning: connect to
mysql server localhost: Can't connect to local MySQL server through
socket '/var/run/mysqld/mysqld.sock' (2)
Mar  5 10:53:22 mail postfix/trivial-rewrite[26046]: fatal:
proxy:mysql:/etc/postfix/mailalias.cf(0,lock|fold_fix): table lookup
problem
Mar  5 10:53:23 mail postfix/master[4283]: warning: process
/usr/lib/postfix/trivial-rewrite pid 26046 exit status 1
Mar  5 10:53:24 mail postfix/trivial-rewrite[29357]: fatal:
proxy:mysql:/etc/postfix/mailalias.cf(0,lock|fold_fix): table lookup
problem
Mar  5 10:53:25 mail postfix/smtpd[29350]: warning: problem talking to
service rewrite: Success
Mar  5 10:53:25 mail postfix/master[4283]: warning: process
/usr/lib/postfix/trivial-rewrite pid 29357 exit status 1
Mar  5 10:53:25 mail postfix/master[4283]: warning:
/usr/lib/postfix/trivial-rewrite: bad command startup -- throttling

mysqld.sock does exist..

mail:~# ls /var/run/mysqld/mysqld.sock
srwxrwxrwx 1 mysql mysql 0 Mar  5 12:14 /var/run/mysqld/mysqld.sock



I rebooted the box and until now I haven't had a repeat of the error.
I suppose it's just possible that after ~500 days uptime a reset was
needed, but I'm always wary when problems like this suddenly appear.
There isn't a heavy load, and so I tend to regard symptoms like this
as highly suspicious.  As per my initial email, I don't think postfix
caused this in anyway, but of course it felt the force of it.  I
wonder now I can increase the redundancy.

Simon

On Mon, Mar 04, 2013 at 01:35:42PM -0600, Noel Jones wrote:
> There's several ways to do this.  I think the easiest is:
>
> # main.cf
> header_checks = regexp:/etc/postfix/header_checks
>
> in your header_checks file:
> /./  REDIRECT someone@...
>
>
> where "someone" is a valid local user, and "example.com" is listed
> in mydestination.

This works perfectly.

Thanks a lot Noel.

--
Nicolas

Simon Brereton:
> Mar  5 08:45:14 mail postfix/proxymap[24831]: warning: mysql query
> failed: MySQL server has gone away

The mysql server closed the connection (or crashed).

> Mar  5 10:53:22 mail postfix/proxymap[26043]: warning: connect to
> mysql server localhost: Can't connect to local MySQL server through
> socket '/var/run/mysqld/mysqld.sock' (2)

The mysql did not accept connections (probably was not running).

	 Wietse

On 5 Mar 2013 19:07, "Wietse Venema" <wietse@...> wrote:
>
> Simon Brereton:
> > Mar  5 08:45:14 mail postfix/proxymap[24831]: warning: mysql query
> > failed: MySQL server has gone away
>
> The mysql server closed the connection (or crashed).
>
> > Mar  5 10:53:22 mail postfix/proxymap[26043]: warning: connect to
> > mysql server localhost: Can't connect to local MySQL server through
> > socket '/var/run/mysqld/mysqld.sock' (2)
>
> The mysql did not accept connections (probably was not running).
>

Thanks Wietse - I'll continue looking for a cause elsewhere..

Simon

Hi ,

I use virtual_alias_maps with a mysql server to manage aliases and
catch-all accounts.
For the past few years this approach worked like a charm, but after
upgrading to 2.10 I get two different behaviours.

When mailing from a domain to a domain both hosted on this server, the
virtual_alias_maps behave correctly.
When mailing from a domain on a different server to one hosted on my
server the alias lookup fails (the message gets through when the actual
user exists).

MySQL log when the email is received from any external mailserver:

130305 21:48:54   283 Query     SELECT `destination` FROM
`virtual_aliases` WHERE source='hazelhof.nl' LIMIT 1
                    284 Query     SELECT 1 FROM `virtual_domains` WHERE
name='hazelhof.nl' LIMIT 1
                    297 Query     SELECT `destination` FROM
`virtual_aliases` WHERE source='info@...' LIMIT 1
                    297 Query     SELECT `destination` FROM
`virtual_aliases` WHERE source='@...' LIMIT 1
                    282 Query     SELECT '/var/mail/hazelhof.nl/alias' AS
`home`, 5000 AS `uid`, 5000 AS `gid`, CONCAT('*:bytes=', quota_kb) AS
`quota_rule` FROM `virtual_users` WHERE `email` = 'alias@...'
LIMIT 1

which results in a reject, Mail.log: Mar  5 21:55:30 black-mail
postfix/smtpd[19444]: NOQUEUE: reject: RCPT from
domain.nl[2a00:d10:101::26:0]: 554 5.7.1 <alias@...>: Recipient
address rejected: Unknown user; from=<info@...>
to=<alias@...> proto=ESMTP helo=<domain.nl>

MySQL log when mailing from an internal domain
130305 21:48:23   283 Query     SELECT `destination` FROM
`virtual_aliases` WHERE source='hazelhof.nl' LIMIT 1
                    284 Query     SELECT 1 FROM `virtual_domains` WHERE
name='hazelhof.nl' LIMIT 1
                    307 Connect   provider@localhost on provider
                    307 Query     SELECT `destination` FROM
`virtual_aliases` WHERE source='michiel@...' LIMIT 1
                    307 Query     SELECT `destination` FROM
`virtual_aliases` WHERE source='@...' LIMIT 1
                    308 Connect   provider@localhost on provider
                    308 Query     SELECT `email` FROM `virtual_users`
WHERE email='michiel@...' LIMIT 1
                    307 Query     SELECT `destination` FROM
`virtual_aliases` WHERE source='alias@...' LIMIT 1
                    307 Query     SELECT `destination` FROM
`virtual_aliases` WHERE source='@...' LIMIT 1
                    283 Query     SELECT `destination` FROM
`virtual_aliases` WHERE source='hazelhof.nl' LIMIT 1
                    284 Query     SELECT 1 FROM `virtual_domains` WHERE
name='hazelhof.nl' LIMIT 1
                    290 Query     SELECT `destination` FROM
`virtual_aliases` WHERE source='alias@...' LIMIT 1
                    290 Query     SELECT `destination` FROM
`virtual_aliases` WHERE source='@...' LIMIT 1
                    290 Query     SELECT `destination` FROM
`virtual_aliases` WHERE source='postmaster@...' LIMIT 1
                    290 Query     SELECT `destination` FROM
`virtual_aliases` WHERE source='postmaster' LIMIT 1
                    290 Query     SELECT `destination` FROM
`virtual_aliases` WHERE source='@...' LIMIT 1
                    283 Query     SELECT `destination` FROM
`virtual_aliases` WHERE source='black-mail.nl' LIMIT 1
                    284 Query     SELECT 1 FROM `virtual_domains` WHERE
name='black-mail.nl' LIMIT 1
                    309 Connect   provider_spamass@localhost on
provider_spamassassin
                    309 Query     set autocommit=1
                    309 Query     SELECT preference, value FROM userpref
WHERE username = 'postmaster@...' OR username = '$GLOBAL' OR
username = CONCAT('%','black-mail.nl') ORDER BY username ASC

Which results in a correct relay to the postmaster account.

It appears to me that there are two different lookups being done, have I
missed something in the 2.10 changelog?

Forgot to add the proper postfinger file.

On Tue, Mar 05, 2013 at 11:19:22PM +0100, Michiel Hazelhof wrote:

> which results in a reject, Mail.log: Mar  5 21:55:30 black-mail
> postfix/smtpd[19444]: NOQUEUE: reject: RCPT from
> domain.nl[2a00:d10:101::26:0]: 554 5.7.1 <alias@...>:
> Recipient address rejected: Unknown user; from=<info@...>
> to=<alias@...> proto=ESMTP helo=<domain.nl>

Nothing in Postfix generates an "Unknown user" response of any kind
(the string "Unknown user" does not appear in the Postfix source
code).  Even such a string were returned it would not be with a
"5.7.1" DSN code, which indicates site policy not address validity.
Perhaps you have a milter or policy service that generates this
response.

--
	 Viktor.

Viktor Dukhovni:
> Arguably, all lookup keys in tables should be in "external" (RFC-5322)
> form. The suggested doubling of internal spaces is far less important
> in practice that avoiding the loss of leading spaces.

Which external form?

- RFC 5321 and 5322 have different rules.

- Worse, The mappings are not one-to-one. That is, there are multiple
correct implementations for quote_821_local() and quote_822_local().

	 Wietse

On Fri, Mar 01, 2013 at 03:19:42PM +0100, Bastian Blank wrote:

> I found that one MTA bounced several mails. The mails where sent to
>  test@... and accepted by Postfix. The backend LMTP then
> rejected the mails.
>
> This is what I found out:
> - RCPT TO:< test@...>
> - The ldap table gets the sanitized address: ` test@...'
>   (note the leading space is still there).
> - This is converted into a ldap query (mail= test@...).
> - The ldap server sanitices the query to (mail=test@...) as
>   mandated by RFC 4717, 4.2.3; it removes the insignificant space.

I see the "insignificant space handling" defined in 4518 (referenced
from 4517).

	 https://tools.ietf.org/html/rfc4518#section-2.6.1

It seems to suggest that exact string matches should take the form

	 attr=<SPACE>value<SPACE>

where any spaces inside the value are encoded as <SPACE><SPACE>.

Is this backwards compatible with older LDAP servers that are not
UTF-8 based?

An easy way to achieve this would be:

	 query_filter = (mail = %s )

if such spaces are not removed at a higher level by the LDAP library.
Does this help?

> Not sure if something should be done about it. At least it is a
> surprising outcome for a simple question; while both parties works
> perfectly fine.

Another thing that could help is if Postfix would use the "external"
form of the address:

	  test@...

with the quotes as the query string. I seem to recall that this is
already the case with lookup keys in virtual_alias_maps, but it
may not be the case with other tables. Which Postfix "mumble_maps"
parameter are you using with LDAP?

Arguably, all lookup keys in tables should be in "external" (RFC-5322)
form. The suggested doubling of internal spaces is far less important
in practice that avoiding the loss of leading spaces.

--
	 Viktor.

On Tue, Mar 05, 2013 at 11:16:18PM -0500, Wietse Venema wrote:

> Viktor Dukhovni:
> > Arguably, all lookup keys in tables should be in "external" (RFC-5322)
> > form. The suggested doubling of internal spaces is far less important
> > in practice that avoiding the loss of leading spaces.
>
> Which external form?
>
> - RFC 5321 and 5322 have different rules.

I was a bit sloppy in my wording, I guess 5321 is the right one
for processing envelope addresses, and perhaps 5322 for processing
header addresses (with canonical and generic rewrites for example).

This complicates recipient extension support, since to compute an
address sans extension we'd need to dequote, lose the extension
and then requote (using the right quoting style).  This is not
trivial.

> - Worse, The mappings are not one-to-one. That is, there are multiple
> correct implementations for quote_821_local() and quote_822_local().

So long as we pick something consistent and documented, users can
likely adapt their table keys.  In most cases the external form
and the internal form are identical, but the exceptions are a pain.

For this specific LDAP issue, if changing the query works that's
the fastest path to success, and we can adjust the ldap_table(5)
document with the latest best practice syntax.

The more things change, the less they stay the same. :-)

--
	 Viktor.

On Wed, Mar 06, 2013 at 03:51:28AM +0000, Viktor Dukhovni wrote:
> On Fri, Mar 01, 2013 at 03:19:42PM +0100, Bastian Blank wrote:
> > - The ldap server sanitices the query to (mail=test@...) as
> >   mandated by RFC 4717, 4.2.3; it removes the insignificant space.
> I see the "insignificant space handling" defined in 4518 (referenced
> from 4517).
>  https://tools.ietf.org/html/rfc4518#section-2.6.1

I forgot that, yes.

> It seems to suggest that exact string matches should take the form
>  attr=<SPACE>value<SPACE>
> where any spaces inside the value are encoded as <SPACE><SPACE>.

This stunt is done to support working substring matches. It does not
help here and you can't trick it by adding more spaces.

> Is this backwards compatible with older LDAP servers that are not
> UTF-8 based?

LDAPv3 was always UTF-8 based.

> An easy way to achieve this would be:
>  query_filter = (mail = %s )
> if such spaces are not removed at a higher level by the LDAP library.
> Does this help?

No, this won't help, as the syntax rules will sanitize also the
additional spaces.

> > Not sure if something should be done about it. At least it is a
> > surprising outcome for a simple question; while both parties works
> > perfectly fine.
> Another thing that could help is if Postfix would use the "external"
> form of the address:
>   test@...
> with the quotes as the query string.

I don't think this would be a good idea. It still includes a N-to-1
mapping of spaces.

I think in this case all queries including spaces should be ignored by
ldap_table, because of the way LDAP works with them.

>                                      I seem to recall that this is
> already the case with lookup keys in virtual_alias_maps, but it
> may not be the case with other tables.

This makes sense. In my tests such addresses where not rewritten as
expected.

>                                        Which Postfix "mumble_maps"
> parameter are you using with LDAP?

transport, virtual_alias, virtual_alias_domains, virtual_mailbox,
virtual_mailbox_domains, relay_recipient, relay_domains

Bastian

--
All your people must learn before you can reach for the stars.
		 -- Kirk, "The Gamesters of Triskelion", stardate 3259.2

Hello,

I had a postfix 2.9.4 and upgraded to 2.10.0 (on CentOS 6.3 x86_64),
building an RPM using Simon J. Mudd's SRPM (for v2.9.x). During
installation, I got:

     warning: /etc/postfix/main.cf created as /etc/postfix/main.cf.rpmnew
     warning: /etc/postfix/master.cf created as /etc/postfix/master.cf.rpmnew
          COMPATIBILITY: editing /etc/postfix/main.cf, overriding
          smtpd_relay_restrictions to prevent inbound mail from unexpectedly
          bouncing.  Specify an empty smtpd_relay_restrictions value to keep
          using smtpd_recipient_restrictions as before.

So, I thought I should set: "smtpd_relay_restrictions = " but I already
have:

     smtpd_relay_restrictions = permit_mynetworks
     permit_sasl_authenticated      defer_unauth_destination

So, is there something I should do? (Updated Postfix seems to be working
fine.)

# postconf -n
allowed_list1 = check_client_access cidr:/etc/postfix/vmail.cidr,reject
allowed_list2 = check_client_access
cidr:/etc/postfix/internalnetworks.cidr,reject
command_directory = /usr/sbin
config_directory = /etc/postfix
content_filter = smtp-amavis:[127.0.0.1]:10024
daemon_directory = /usr/libexec/postfix
data_directory = /var/lib/postfix
debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin
xxgdb $daemon_directory/$process_name $process_id & sleep 5
default_process_limit = 50
disable_vrfy_command = yes
enable_long_queue_ids = yes
html_directory = no
inet_interfaces = all
inet_protocols = ipv4, ipv6
local_recipient_maps =
local_transport = error:local mail delivery is disabled
mail_name = NOA Mail Srv XAPITI XPICTOY
mail_owner = postfix
mailq_path = /usr/bin/mailq.postfix
manpage_directory = /usr/share/man
message_size_limit = 15728640
mydestination =
mynetworks = 127.0.0.1/32 [::1]/128
myorigin = $mydomain
newaliases_path = /usr/bin/newaliases.postfix
postscreen_dnsbl_action = enforce
postscreen_dnsbl_sites = b.barracudacentral.org*2, zen.spamhaus.org*2,
psbl.surriel.com*2
postscreen_dnsbl_threshold = 2
postscreen_greet_action = enforce
queue_directory = /var/spool/postfix
relay_domains = noa.gr, astro.noa.gr, admin.noa.gr, nestor.noa.gr
space.noa.gr, meteo.noa.gr, gein.noa.gr, technet.noa.gr
relay_recipient_maps =
sendmail_path = /usr/sbin/sendmail.postfix
setgid_group = postdrop
smtpd_recipient_restrictions = check_sender_access
hash:/etc/postfix/blacklisted_senders, reject_unverified_recipient,
reject_unauth_destination, check_recipient_access
hash:/etc/postfix/protected_destinations, permit_mynetworks,
reject_invalid_hostname, reject_unauth_pipelining,
reject_non_fqdn_sender, reject_unknown_sender_domain,
reject_non_fqdn_recipient, reject_unknown_recipient_domain,
reject_rbl_client b.barracudacentral.org, reject_rbl_client
zen.spamhaus.org, reject_rbl_client psbl.surriel.com,
reject_rhsbl_client dbl.spamhaus.org, reject_rhsbl_sender
dbl.spamhaus.org, reject_rhsbl_helo dbl.spamhaus.org,
check_policy_service unix:postgrey/socket, permit
smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated
defer_unauth_destination
smtpd_restriction_classes = allowed_list1,allowed_list2
transport_maps = hash:/etc/postfix/transportmap
unknown_local_recipient_reject_code = 550
unverified_sender_reject_code = 550
virtual_alias_maps = hash:/etc/postfix/virtualmap

Thanks,
Nick

Am 06.03.2013 11:08, schrieb Nikolaos Milas:

> I had a postfix 2.9.4 and upgraded to 2.10.0 (on CentOS 6.3 x86_64), building
an RPM using Simon J. Mudd's SRPM
> (for v2.9.x). During installation, I got:
>
>    warning: /etc/postfix/main.cf created as /etc/postfix/main.cf.rpmnew
>    warning: /etc/postfix/master.cf created as /etc/postfix/master.cf.rpmnew
>         COMPATIBILITY: editing /etc/postfix/main.cf, overriding
>         smtpd_relay_restrictions to prevent inbound mail from unexpectedly
>         bouncing.  Specify an empty smtpd_relay_restrictions value to keep
>         using smtpd_recipient_restrictions as before.
>
> So, I thought I should set: "smtpd_relay_restrictions = "

which would kill your server

> but I already have:
>
>    smtpd_relay_restrictions = permit_mynetworks
>    permit_sasl_authenticated      defer_unauth_destination
>
> So, is there something I should do? (Updated Postfix seems to be working
fine.)

if "smtpd_relay_restrictions = permit_mynetworks" is what you want use it
the new default is for instalaltions which did not set it at all and
especially for completly new setups to minimize the danger of a open
relay more as before

Hi,

I'm currently upgrading from postfix 2.9 to 2.10 with haproxy 1.5-dev17

So far, everythink works fine with:
:/etc/haproxy/haproxy.cfg:

frontend ft_smtps
      bind :465
      mode tcp
      default_backend bk_smtps

frontend ft_submission
      bind :587
      mode tcp
      default_backend bk_submission

backend bk_smtps
      mode tcp
      balance source
      stick store-request src
      stick-table type ip size 200k
      server smtps_mailout-vty-001 192.168.100.16:1465 weight 200 check
      server smtps_mailout-vty-002 192.168.100.17:1465 weight 200 check

backend bk_submission
      mode tcp
      balance source
      stick store-request src
      stick-table type ip size 200k
      server submission_mailout-vty-001 192.168.100.16:1587 send-proxy
weight 200 check
      server submission_mailout-vty-002 192.168.100.17:1587 send-proxy
weight 200 check

So far, everything works as expected between haproxy and postfix as long
as I use the submission port.

When using the SSMTP port *and* send-proxy it fails.

The workaround so far has then be to:
:main.cf:
- remove smtpd_upstream_proxy_protocol=haproxy
- remove smtpd_upstream_proxy_timeout=5s
:master.cf:
- add -o smtpd_upstream_proxy_protocol=haproxy
- add -o smtpd_upstream_proxy_timeout=5s

leading to the use og the proxy protocol only for submission but not for
SMTPS.

Did I miss something obvious ?

Thanks

Laurent

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 3/6/2013 4:19 AM, Reindl Harald wrote:
>
>
> Am 06.03.2013 11:08, schrieb Nikolaos Milas:
>
>> I had a postfix 2.9.4 and upgraded to 2.10.0 (on CentOS 6.3
>> x86_64), building an RPM using Simon J. Mudd's SRPM (for
>> v2.9.x). During installation, I got:
>>
>> warning: /etc/postfix/main.cf created as
>> /etc/postfix/main.cf.rpmnew warning: /etc/postfix/master.cf
>> created as /etc/postfix/master.cf.rpmnew COMPATIBILITY:
>> editing /etc/postfix/main.cf, overriding
>> smtpd_relay_restrictions to prevent inbound mail from
>> unexpectedly bouncing.  Specify an empty
>> smtpd_relay_restrictions value to keep using
>> smtpd_recipient_restrictions as before.
>>
>> So, I thought I should set: "smtpd_relay_restrictions = "
>
> which would kill your server

Kill seems the wrong word here.

This is, in fact, one of the recommended choices for backward
compatibility.  This disables the new smtpd_relay_restrictions
feature and causes postfix to behave exactly as before.  Setting
"smtpd_relay_restrictions = " is very unlikely to break an
existing, working installation, but you lose the benefit of the
new feature.

See RELEASE_NOTES for details.

>
>> but I already have:
>>
>> smtpd_relay_restrictions = permit_mynetworks
>> permit_sasl_authenticated      defer_unauth_destination

This is the safety net added by the postfix upgrade procedure.
See RELEASE_NOTES for details.


>>
>> So, is there something I should do? (Updated Postfix seems to
>> be working fine.)


If you have a "standard" setup, change the above
defer_unauth_destination to reject_unauth_destination.  If you
have a complex relay policy already defined in
smtpd_recipient_restrictions, then set smtpd_relay_restrictions
empty.  See RELEASE_NOTES for details.



   -- Noel Jones
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRNzhGAAoJEJGRUHb5Oh6g19IIAJY4rARiNqF1MTf33Vxb+mp6
PiIN4tYiAUsdgt4Digh7fptohMa3G2OpLkHd+wTlzpuB75lSvN3OIXdT1KZjQhCT
EEk8jxDZG8uYi8lEuoT89w6sebyhbWlT95+T+8dcpj3DUxqgTG8jsNtmz41hHjjb
UG6IC6PmOXemtdhCVqSaLNymBVDPpdfbeSEeEkyR3B2MF5qaZoIRWwWkpQtb6Wwl
TBzTBgFt1EBQ7AtN1IrBTU8XizAKlXeQZK7BB8j0cPG+Amsf76cnoKOv+vEEpoot
/Rc/3rMO+01Wmrua1NcAIycL2vkcWCChqSvnj0akA2JH5ECOkiuAsmriSYfKFLQ=
=gOiV
-----END PGP SIGNATURE-----