> On Dec 11, 2020, at 1:46 PM, Sergio Belkin wrote:
>
> Ok, I thought so because of the 'indexed' parameter that I don't found in
> documentation except in tls_server_sni_maps
> (http://www.postfix.org/postconf.5.html)
> Is that parameter supported in postfix 2.10.1?
There is no built-in "ind
Sergio Belkin:
> El vie, 11 dic 2020 a las 12:30, Viktor Dukhovni (<
> postfix-us...@dukhovni.org>) escribi?:
>
> > > On Dec 11, 2020, at 12:21 PM, Sergio Belkin wrote:
> > >
> > > VIktor, I'm considering replace dnsmasq with unbound. Meanwhile, I'm
> > loggind the DNS queries made by dnsmasq.
>
El vie, 11 dic 2020 a las 12:30, Viktor Dukhovni (<
postfix-us...@dukhovni.org>) escribió:
> > On Dec 11, 2020, at 12:21 PM, Sergio Belkin wrote:
> >
> > VIktor, I'm considering replace dnsmasq with unbound. Meanwhile, I'm
> loggind the DNS queries made by dnsmasq.
> > The debug method you sugges
> On Dec 11, 2020, at 12:21 PM, Sergio Belkin wrote:
>
> VIktor, I'm considering replace dnsmasq with unbound. Meanwhile, I'm loggind
> the DNS queries made by dnsmasq.
> The debug method you suggest needs SNI support, isn't it? Because my postfix
> versions lacks support of it :(
No, SNI is n
El mar, 8 dic 2020 a las 17:50, Viktor Dukhovni ()
escribió:
> On Thu, Dec 03, 2020 at 11:22:29PM -0200, Viktor Dukhovni wrote:
>
> > The only possible explanations are:
> >
> >- Your resolver erroneously reported NODATA for IPv4
> >- The authoritative nameservers reported NODATA for IPv4
On Thu, Dec 03, 2020 at 11:22:29PM -0200, Viktor Dukhovni wrote:
> The only possible explanations are:
>
>- Your resolver erroneously reported NODATA for IPv4
>- The authoritative nameservers reported NODATA for IPv4
>- Neither of us was able to spot a subtle bug
>
> To distinguish b
> On Dec 4, 2020, at 9:41 AM, Sergio Belkin wrote:
>
> > dnsmasq-2.76-7.el7.x86_64
>
> Is there a compelling reason to run a stripped-down (and typically not
> adequately standards-conformant) DNS resolvers on a mail server?
>
> I use mainly for caching purposes
That's a reason to run a local
El vie, 4 dic 2020 a las 9:59, Wietse Venema ()
escribió:
> Sergio Belkin:
> > Some information about my software that may be useful:
> > libc-2.17-260.el7_6.4.x86_64
> > glibc-2.17-260.el7_6.4.i686
> > dnsmasq-2.76-7.el7.x86_64
>
> Are you running a RHEL port of Postfix 2.10? They sometimes back-
* Matus UHLAR - fantomas [2020-12-04 15:08]:
> > El vie, 4 dic 2020 a las 2:15, Viktor Dukhovni
> > () escribió:
> > > Is there a compelling reason to run a stripped-down (and typically not
> > > adequately standards-conformant) DNS resolvers on a mail server?
>
> On 04.12.20 08:41, Sergio Belkin
On Fri, Dec 04, 2020 at 01:42:57AM -0300, Sergio Belkin wrote:
> Thanks Viktor and Wietse, up to now the error didn't happen again.
> Some information about my software that may be useful:
> libc-2.17-260.el7_6.4.x86_64
> glibc-2.17-260.el7_6.4.i686
> dnsmasq-2.76-7.el7.x86_64
El vie, 4 dic 202
Sergio Belkin:
> Some information about my software that may be useful:
> libc-2.17-260.el7_6.4.x86_64
> glibc-2.17-260.el7_6.4.i686
> dnsmasq-2.76-7.el7.x86_64
Are you running a RHEL port of Postfix 2.10? They sometimes back-port
features from a later Postfix release. The Postfix code that handle
El vie, 4 dic 2020 a las 2:15, Viktor Dukhovni ()
escribió:
> On Fri, Dec 04, 2020 at 01:42:57AM -0300, Sergio Belkin wrote:
>
> > Thanks Viktor and Wietse, up to now the error didn't happen again.
> > Some information about my software that may be useful:
> > libc-2.17-260.el7_6.4.x86_64
> > glib
On Fri, Dec 04, 2020 at 01:42:57AM -0300, Sergio Belkin wrote:
> Thanks Viktor and Wietse, up to now the error didn't happen again.
> Some information about my software that may be useful:
> libc-2.17-260.el7_6.4.x86_64
> glibc-2.17-260.el7_6.4.i686
> dnsmasq-2.76-7.el7.x86_64
Is there a compelli
El vie, 4 dic 2020 a las 1:42, Sergio Belkin () escribió:
>
>
> El jue, 3 dic 2020 a las 22:23, Viktor Dukhovni (<
> postfix-us...@dukhovni.org>) escribió:
>
>> > On Dec 3, 2020, at 7:28 PM, Sergio Belkin wrote:
>> >
>> > Thanks Bastian, I had to obfuscate the domain name due to privacy
>> issues
El jue, 3 dic 2020 a las 22:23, Viktor Dukhovni ()
escribió:
> > On Dec 3, 2020, at 7:28 PM, Sergio Belkin wrote:
> >
> > Thanks Bastian, I had to obfuscate the domain name due to privacy issues
> :-/
> > But I told to Wietse, that domain name has a MX record with an 'A'
> record associated, but
> On Dec 3, 2020, at 7:28 PM, Sergio Belkin wrote:
>
> Thanks Bastian, I had to obfuscate the domain name due to privacy issues :-/
> But I told to Wietse, that domain name has a MX record with an 'A' record
> associated, but lacks of '' record.
> What is weird for me is that it happens some
El jue, 3 dic 2020 a las 18:04, Bastian Blank () escribió:
> Hi Sergio
>
> On Thu, Dec 03, 2020 at 05:34:45PM -0300, Sergio Belkin wrote:
> > Is quite interesting that I find the following in logs:
> > Dec 2 23:53:09 muteriver postfix/smtp[28063]: warning: no MX host for
> > another-example.com h
> > not accessible.
> > >
> > > 2) You ran the command outside the Postfix chroot jail, and the
> > > Postfix SMTP client runs inside the Postfix chroot jail. Name
> > > resolution fails inside the chroot jail when files are missing,
> > > have wrong
root jail, and the
> > Postfix SMTP client runs inside the Postfix chroot jail. Name
> > resolution fails inside the chroot jail when files are missing,
> > have wrong permissions, or have wrong contents.
> >
> > 3) Some "security" configuration is breaking P
you think?
>
> What comes to mind:
>
> 1) You ran the command as root, and the Postfix SMTP client does
> not run as root. Name resution fails when the necessary files are
> not accessible.
>
> 2) You ran the command outside the Postfix chroot jail, and the
> Postfix SMTP cl
Hi Sergio
On Thu, Dec 03, 2020 at 05:34:45PM -0300, Sergio Belkin wrote:
> Is quite interesting that I find the following in logs:
> Dec 2 23:53:09 muteriver postfix/smtp[28063]: warning: no MX host for
> another-example.com has a valid address record
Well, more serious: another-example.com does
gt; What do you think?
What comes to mind:
1) You ran the command as root, and the Postfix SMTP client does
not run as root. Name resution fails when the necessary files are
not accessible.
2) You ran the command outside the Postfix chroot jail, and the
Postfix SMTP client runs inside the Postfi
On Thu, Dec 03, 2020 at 05:34:45PM -0300, Sergio Belkin wrote:
> Dec 2 23:53:09 muteriver postfix/smtp[28063]: ED1CF1813C56F: to=<
> apere...@another-example.com>, relay=none, delay=5.9, delays=0.17/0/5.8/0,
> dsn=5.4.4, status=bounced (Host or domain name not found. Name service
> error for name
El jue, 3 dic 2020 a las 16:37, Wietse Venema ()
escribió:
> Sergio Belkin:
> > smtp_address_preference = any
> > inet_protocols = all
> ...
> > : Host or domain name not found. Name
> > service error for
> > name=another-example.com.mail.protection.outlook.com type=: Host
> > found but no dat
Sergio Belkin:
> smtp_address_preference = any
> inet_protocols = all
...
> : Host or domain name not found. Name
> service error for
> name=another-example.com.mail.protection.outlook.com type=: Host
> found but no data record of requested type
>
>
> AFAIK if DNS over IPv6 fails it tries ove
Hi folks,
I have a postfix 2.10 with the following parameters set:
smtp_address_preference = any
inet_protocols = all
Sometimes users get this kind of errors:
This is the mail system at host groupware.example.com.
I'm sorry to have to inform you that your message could not
be delivered to one
..@postfix.org]
> Namens Bill Shirley
> Verzonden: vrijdag 5 februari 2016 5:21
> Aan: postfix-users@postfix.org
> Onderwerp: Re: Change Temporary failure in name resolution response
> code
>
> You might want to have a look at fail2ban. It monitors log files and
> block
g 5 februari 2016 5:21
> Aan: postfix-users@postfix.org
> Onderwerp: Re: Change Temporary failure in name resolution response code
>
> You might want to have a look at fail2ban. It monitors log files and
> blocks the offender by inserting an iptables DROP entry.
>
> I blo
k you Wietse,
450 it is then.
Razvan Constantin
-Original Message-
From: owner-postfix-us...@postfix.org
[mailto:owner-postfix-us...@postfix.org] On Behalf Of Wietse Venema
Sent: Thursday, February 04, 2016 11:06 PM
To: Postfix users
Subject: Re: Change Temporary failure in name resol
name resolution response code
Inteq Solution - Dep. Tehnic:
> "The unknown_client_reject_code parameter specifies the response code
> for rejected requests (default: 450). The reply is always 450 in case
> the
> address->name or name->address lookup failed due to a temporar
Inteq Solution - Dep. Tehnic:
> "The unknown_client_reject_code parameter specifies the response code for
> rejected requests (default: 450). The reply is always 450 in case the
> address->name or name->address lookup failed due to a temporary problem."
>
> But is there a way to change this behavi
not resolve to address 5.35.210.92:
Temporary failure in name resolution
NOQUEUE: reject: RCPT from unknown[5.35.210.92]: 450 4.7.1 Client host
rejected: cannot find your hostname
# host ip92.llpdynamics.com
;; connection timed out; no servers could be reached
I know that Postifx
Viktor Dukhovni:
> I gather you're suggesting a chang along the lines of:
>
> diff --git a/src/smtpstone/smtp-sink.c b/src/smtpstone/smtp-sink.c
> index 617fbf9..33872b0 100644
I came up with similar code. It works without surprises.
Wietse
:10055
>
> and the smtp-sink aborts with:
>
> smtp-sink: fatal: sockaddr_to_hostaddr: Non-recoverable failure in name
> resolution
>
>
> Turns out that the problem is a structure declared too short
> by two bytes to receive a sockaddr_in6 from accept(),
> and t
Mark Martinec:
> Turns out that the problem is a structure declared too short
> by two bytes to receive a sockaddr_in6 from accept(),
> and the two bytes of a received IP address are then clobbered.
>
> In smtp-sink.c/connect_event() the sa is declared
> as struct sockaddr instead of struct sockad
ilure in name
resolution
Turns out that the problem is a structure declared too short
by two bytes to receive a sockaddr_in6 from accept(),
and the two bytes of a received IP address are then clobbered.
In smtp-sink.c/connect_event() the sa is declared
as struct sockaddr instead of s
>> Thanks. So my understanding is correct that Postfix gets the hostnames you
> see in the logs from PTR records?
>
> Yes.
>
>> You are saying that additionally, if the A record for the domain
> doesn't match the client IP, the PTR will be ignored and thus you'll
> still get "unknown"?
>
E.B. wrote:
> Thanks. So my understanding is correct that Postfix gets the hostnames you
> see in the logs from PTR records?
Yes.
> And that "connect from unknown[1.2.3.4]" is caused by a missing PTR (or DNS
> issue)?
A missing PTR is one cause. A DNS glitch that means the PTR lookup
fails is
>>> Hello,
>>>
>>> My understanding was clients for whom you see this in the logs:
>>>
>>> connect from unknown[1.2.3.4]
>>>
>>> Do not have a PTR/rDNS set up for themselves.
>>
>> For Postfix to include the rDNS in the log and Received: header, the PTR
>> name must then resolve back
> On Monday, November 18, 2013 7:57 AM, Kris Deugau wrote:
> > E.B. wrote:
>
>> Hello,
>>
>> My understanding was clients for whom you see this in the logs:
>>
>> connect from unknown[1.2.3.4]
>>
>> Do not have a PTR/rDNS set up for themselves.
>
> For Postfix to include the rDNS in
E.B. wrote:
> Hello,
>
> My understanding was clients for whom you see this in the logs:
>
> connect from unknown[1.2.3.4]
>
> Do not have a PTR/rDNS set up for themselves.
For Postfix to include the rDNS in the log and Received: header, the PTR
name must then resolve back to that same IP as we
On Mon, Nov 18, 2013 at 03:43:17AM -0800, E.B. wrote:
> I did "dig -x 1.2.3.4" on the server for the same IP address and the result
> came back with the correct domain name. So why didn't postfix see the host
> name? I restarted postfix in case it was caching, but it didn't help.
Show proof. Es
Am 18.11.2013 12:43, schrieb E.B.:
> My understanding was clients for whom you see this in the logs:
>
> connect from unknown[1.2.3.4]
>
> Do not have a PTR/rDNS set up for themselves. However, I recently tested a
> connection (using telnet on the client side, connecting to port 25) from a
>
Hello,
My understanding was clients for whom you see this in the logs:
connect from unknown[1.2.3.4]
Do not have a PTR/rDNS set up for themselves. However, I recently tested a
connection (using telnet on the client side, connecting to port 25) from a
server that does have rDNS in place, but I
On Tue, 22 May 2012, Wietse Venema wrote:
Barbara M.:
Thanks.
I put:
smtp_host_lookup = native, dns
In my idea this give higher priority to /etc/hosts
Postfix works as documented. See:
http://www.postfix.org/postconf.5.html#smtp_host_lookup
Then search for any text that promises that Post
Barbara M.:
> Thanks.
>
> I put:
>
> smtp_host_lookup = native, dns
>
> In my idea this give higher priority to /etc/hosts
Postfix works as documented. See:
http://www.postfix.org/postconf.5.html#smtp_host_lookup
Then search for any text that promises that Postfix
gives priority. If such text
On Tue, 22 May 2012, Reindl Harald wrote:
Am 22.05.2012 12:15, schrieb Barbara M.:
# telnet mail.aaa.tld 25
Trying 192.168.1.25...
Connected to mail.aaa.tld.
Escape character is '^]'.
220 mail.aaa.tld ESMTP
. . . .
but Postfix seems to still search the real IP via DNS.
Why?
Any trick/config
Barbara M.:
>
> How work name resolution in Postfix?
>
http://www.postfix.org/postconf.5.html#smtp_host_lookup
Wietse
smtp_host_lookup (default: dns)
What mechanisms the Postfix SMTP client uses to look up a host's
IP address. This parameter is ignored when D
On 05/22/12 12:15, Barbara M. wrote:
> Any trick/config/workaround to force Postfix to consider /etc/hosts?
To use other data sources than DNS you need the smtp_host_lookup option
(http://www.postfix.org/postconf.5.html#smtp_host_lookup).
--
Martin
Am 22.05.2012 12:15, schrieb Barbara M.:
> # telnet mail.aaa.tld 25
> Trying 192.168.1.25...
> Connected to mail.aaa.tld.
> Escape character is '^]'.
> 220 mail.aaa.tld ESMTP
> . . . .
>
>
> but Postfix seems to still search the real IP via DNS.
>
> Why?
> Any trick/config/workaround to force
How work name resolution in Postfix?
I have an internal server that resend mail to another box (in the same
IntraNet).
If I put in my local /etc/hosts something like:
192.168.1.25mail.aaa.tld
the box do what I want:
# ping mail.aaa.tld
PING mail.aaa.tld (192.168.1.25) 56(84) bytes of
51 matches
Mail list logo
