Wietse Venema:
> Ralf Hildebrandt:
> > * Ralf Hildebrandt <ralf.hildebra...@charite.de>:
> > > Which Postfix restriction generates: "Helo command rejected: Domain not
> > > found"?
> > >
> > > From the log on albatross.python.org:
> > >
> > > Aug 21 15:07:07 albatross postfix/smtpd[15378]: NOQUEUE: reject_warning:
> > > RCPT from qmta09.emeryville.ca.mail.comcast.net[76.96.30.96]: 554 5.0.0
> > > <QMTA09.emeryville.ca.mail.comcast.net>: Helo command rejected: Domain
> > > not found; from=<rickbk...@comcast.net> to=<python-l...@python.org>
> > > proto=ESMTP helo=<QMTA09.emeryville.ca.mail.comcast.net>
> >
> > BTW, this log entry in itself proves that the DNS name must resolved
> > back and forth, because otherwise postfix would have logged
> > "unknown[76.96.30.96]" instead of
> > qmta09.emeryville.ca.mail.comcast.net[76.96.30.96]
> > -- which was also the HELO hostname!
>
> This happens because their name server gives out unexpected responses:
>
> % host -t ns emeryville.ca.mail.comcast.net
> Host emeryville.ca.mail.comcast.net not found: 3(NXDOMAIN)
>
> When qmta09.emeryville... exists, an NXDOMAIN for a parent domain
> is not expected.
>
> This happens with check_{client,helo,etc.}_ns_access, which now
> requires that Postfix can find the qmta09..'s name server by asking
> for an NS record for the name itself or for its parent domains.
>
> When the qmta09... name exists, and the name server lookups fail,
> Postfix rejects the mail because someone claimed that allowing the
> mail was a Postfix loophole in check_{client,helo,etc.}_ns_access.
These changes were first released August 7, and it is unfortunate
that the problems did not surface after this week when I released
updates for Postfix 2.3, 2.4, 2.5, 2.6. 2,7 and the non-prod release.
I really don't have time because of a hard deadline, so I am going
to roll back these changes and re-issue six Postfix releases.
Wietse
