Re: [SOLVED] Re: A bug, maybe?

2016-02-23 Thread Peter 
On 23/02/16 08:57, Curtis Maurand wrote:
> The problem was in the /etc/nsswitch.conf. 
> 
> I changed the line
> 
> hosts:   files dns
> 
> to
> 
> hosts:dns files
> 
> and that solved the trouble.

You likely want this to be, "files dns", otherwise with dns listed first
you will find that you can't override DNS entries from /etc/hosts.  The
real issue is twofold:

1.  As already pointed out you had the problematic domain (incorrectly?)
listed in /etc/hosts.

2.  You have smtp_host_lookup explicitly set to "native" in your
main.cf.  This is likely best left at the default of "dns" unless you
have a specific reason to want postfix to check the /etc/hosts file
before doing dns lookups.


Peter

Re: [SOLVED] Re: A bug, maybe?

2016-02-22 Thread Curtis Maurand 



On 2/22/2016 3:03 PM, Viktor Dukhovni wrote:

On Mon, Feb 22, 2016 at 02:57:23PM -0500, Curtis Maurand wrote:


The problem was in the /etc/nsswitch.conf.
I changed the line
 hosts:   files dns
to
 hosts:dns files
and that solved the trouble.

Is "delivery.mailspamprotection.com" listed in /etc/hosts?

If so, then the wound was self-inflicted.  If not, then the C-library
getaddrinfo() is buggy, since skipping all the non-matching entries
in /etc/hosts should have no effect on the results from DNS.

Why yes it was.  I don't even remember doing that.

I will sheepishly return to my corner, now, with my head bowed in 
embarrassment.  I'll need a bandage to stop the bleeding.


--Curtis


--
Curtis Maurand
cur...@maurand.com 
207-252-7748

Re: [SOLVED] Re: A bug, maybe?

2016-02-22 Thread Viktor Dukhovni 
On Mon, Feb 22, 2016 at 02:57:23PM -0500, Curtis Maurand wrote:

> The problem was in the /etc/nsswitch.conf.
> I changed the line
> hosts:   files dns
> to
> hosts:dns files
> and that solved the trouble.

Is "delivery.mailspamprotection.com" listed in /etc/hosts?

If so, then the wound was self-inflicted.  If not, then the C-library
getaddrinfo() is buggy, since skipping all the non-matching entries
in /etc/hosts should have no effect on the results from DNS.

-- 
Viktor.

Re: [SOLVED] Re: A bug, maybe?

2016-02-22 Thread Danny Horne 
On 22/02/2016 7:57 pm, Curtis Maurand wrote:
>
> The problem was in the /etc/nsswitch.conf. 
>
> I changed the line
>
> hosts:   files dns
>
> to
>
> hosts:dns files
>
> and that solved the trouble.

Interesting, I got the IP result Viktor got, but have the same
nsswitch.conf setting as your original



signature.asc
Description: OpenPGP digital signature

[SOLVED] Re: A bug, maybe?

2016-02-22 Thread Curtis Maurand 



On 2/20/2016 5:19 PM, Curtis Maurand wrote:



On 2/20/2016 1:46 PM, Viktor Dukhovni wrote:

On Sat, Feb 20, 2016 at 01:37:39PM -0500, Curtis Maurand wrote:


Nothing is chrooted.  resolv.conf is world readable.  Wietse's program
returns a valid address.  It might not match the reverse, but it did return
an address.
# ./getaddr delivery.mailspamprotection.com
Hostname:   delivery.mailspamprotection.com
Addresses:  108.163.228.171

There's your problem, it is supposed to return *all* the addresses.  On
my system:

 $ ./getaddrinfo delivery.mailspamprotection.com
 Hostname:   delivery.mailspamprotection.com
 Addresses:  108.163.220.52 108.163.201.229 69.175.69.94 
108.163.204.150 198.143.161.10 108.163.201.230 96.127.190.5 184.154.58.227 
198.143.161.21 184.154.48.173 198.143.161.29 69.175.69.92 108.163.243.190 
96.127.190.4 198.143.161.30 108.178.24.182 108.163.243.188 108.163.228.171 
69.175.69.93 184.154.208.34 184.154.208.36 96.127.176.253 96.127.190.2 
198.143.161.27 108.163.220.54 198.143.161.11 108.163.228.170 198.143.161.13 
184.154.58.230 108.163.243.189 108.163.228.174 108.163.201.228 108.178.24.171 
108.163.201.226 108.178.24.181 108.163.201.227 184.154.208.37 108.178.24.174 
198.143.161.12 184.154.48.171 96.127.176.250 108.163.243.186 108.178.24.180 
69.175.69.90 108.163.243.187 108.163.228.172 96.127.176.252 184.154.177.50 
184.154.48.172 108.163.204.148 198.143.161.28 108.163.204.146 184.154.208.35 
108.163.204.149 96.127.190.6 69.175.69.91 184.154.58.226 108.163.228.173 
108.178.24.173 108.178.24.178 96.127.176.254 198.143.161.18 184.154.48.174 
198.143.161.20 184.154.58.229 1
08.163.220.51 96.127.176.251 108.163.220.50 108.178.24.170 108.163.220.53 
198.143.161.22 184.154.208.38 184.154.48.170 184.154.58.228 108.178.24.172 
198.143.161.14 108.178.24.179 198.143.161.19 108.163.204.147 198.143.161.26 
96.127.190.3

If your getaddrinfo returns only the first address, it is busted.
Perhaps this is controlled via /etc/hosts.conf:

 http://www.linfo.org/etc_host_conf.html

 /etc/hosts.conf:
multi on


That said.  Since the unit has been updated, but not rebooted, I may need to
reboot to get the kernel fix.  Ubuntu does, at least, backport fixes.

The getaddrinfo issue is not resolved via a kernel fix, it is
addressed via a glibc fix.


interesting.  on my 12.04 mail server it works correctly.  on the 
14.04 server it is not.  both have "multi on" set.  I fired up another 
virtual machine with 14.04 installed and that one works fine.  As a 
work around, I've set my mx to the 12.04 machine that works with a 
transport command that sends the mail to the host that should be 
receiving the mail.  the machine that is not working right claims to 
not have any updates available, thought the getaddrinfo() has been 
patched.  frustrating.  Thank you for your help.  The problem appears 
to not be postfix.


The problem was in the /etc/nsswitch.conf.

I changed the line

hosts:   files dns

to

hosts:dns files

and that solved the trouble.

--
Curtis Maurand
cur...@maurand.com 
207-252-7748

Re: A bug, maybe?

2016-02-20 Thread Curtis Maurand 



On 2/20/2016 1:46 PM, Viktor Dukhovni wrote:

On Sat, Feb 20, 2016 at 01:37:39PM -0500, Curtis Maurand wrote:


Nothing is chrooted.  resolv.conf is world readable.  Wietse's program
returns a valid address.  It might not match the reverse, but it did return
an address.
# ./getaddr delivery.mailspamprotection.com
Hostname:   delivery.mailspamprotection.com
Addresses:  108.163.228.171

There's your problem, it is supposed to return *all* the addresses.  On
my system:

 $ ./getaddrinfo delivery.mailspamprotection.com
 Hostname:   delivery.mailspamprotection.com
 Addresses:  108.163.220.52 108.163.201.229 69.175.69.94 
108.163.204.150 198.143.161.10 108.163.201.230 96.127.190.5 184.154.58.227 
198.143.161.21 184.154.48.173 198.143.161.29 69.175.69.92 108.163.243.190 
96.127.190.4 198.143.161.30 108.178.24.182 108.163.243.188 108.163.228.171 
69.175.69.93 184.154.208.34 184.154.208.36 96.127.176.253 96.127.190.2 
198.143.161.27 108.163.220.54 198.143.161.11 108.163.228.170 198.143.161.13 
184.154.58.230 108.163.243.189 108.163.228.174 108.163.201.228 108.178.24.171 
108.163.201.226 108.178.24.181 108.163.201.227 184.154.208.37 108.178.24.174 
198.143.161.12 184.154.48.171 96.127.176.250 108.163.243.186 108.178.24.180 
69.175.69.90 108.163.243.187 108.163.228.172 96.127.176.252 184.154.177.50 
184.154.48.172 108.163.204.148 198.143.161.28 108.163.204.146 184.154.208.35 
108.163.204.149 96.127.190.6 69.175.69.91 184.154.58.226 108.163.228.173 
108.178.24.173 108.178.24.178 96.127.176.254 198.143.161.18 184.154.48.174 
198.143.161.20 184.154.58.229 108.163.220.51 96.127.176.251 108.163.220.50 
108.178.24.170 108.163.220.53 198.143.161.22 184.154.208.38 184.154.48.170 
184.154.58.228 108.178.24.172 198.143.161.14 108.178.24.179 198.143.161.19 
108.163.204.147 198.143.161.26 96.127.190.3

If your getaddrinfo returns only the first address, it is busted.
Perhaps this is controlled via /etc/hosts.conf:

 http://www.linfo.org/etc_host_conf.html

 /etc/hosts.conf:
multi on


That said.  Since the unit has been updated, but not rebooted, I may need to
reboot to get the kernel fix.  Ubuntu does, at least, backport fixes.

The getaddrinfo issue is not resolved via a kernel fix, it is
addressed via a glibc fix.


interesting.  on my 12.04 mail server it works correctly.  on the 14.04 
server it is not.  both have "multi on" set.  I fired up another virtual 
machine with 14.04 installed and that one works fine.  As a work around, 
I've set my mx to the 12.04 machine that works with a transport command 
that sends the mail to the host that should be receiving the mail.  the 
machine that is not working right claims to not have any updates 
available, thought the getaddrinfo() has been patched.  frustrating.  
Thank you for your help.  The problem appears to not be postfix.



--
Curtis Maurand
cur...@maurand.com 
207-252-7748

Re: A bug, maybe?

2016-02-20 Thread Viktor Dukhovni 
On Sat, Feb 20, 2016 at 01:37:39PM -0500, Curtis Maurand wrote:

> Nothing is chrooted.  resolv.conf is world readable.  Wietse's program
> returns a valid address.  It might not match the reverse, but it did return
> an address.
> # ./getaddr delivery.mailspamprotection.com
> Hostname:   delivery.mailspamprotection.com
> Addresses:  108.163.228.171

There's your problem, it is supposed to return *all* the addresses.  On
my system:

$ ./getaddrinfo delivery.mailspamprotection.com
Hostname:   delivery.mailspamprotection.com
Addresses:  108.163.220.52 108.163.201.229 69.175.69.94 108.163.204.150 
198.143.161.10 108.163.201.230 96.127.190.5 184.154.58.227 198.143.161.21 
184.154.48.173 198.143.161.29 69.175.69.92 108.163.243.190 96.127.190.4 
198.143.161.30 108.178.24.182 108.163.243.188 108.163.228.171 69.175.69.93 
184.154.208.34 184.154.208.36 96.127.176.253 96.127.190.2 198.143.161.27 
108.163.220.54 198.143.161.11 108.163.228.170 198.143.161.13 184.154.58.230 
108.163.243.189 108.163.228.174 108.163.201.228 108.178.24.171 108.163.201.226 
108.178.24.181 108.163.201.227 184.154.208.37 108.178.24.174 198.143.161.12 
184.154.48.171 96.127.176.250 108.163.243.186 108.178.24.180 69.175.69.90 
108.163.243.187 108.163.228.172 96.127.176.252 184.154.177.50 184.154.48.172 
108.163.204.148 198.143.161.28 108.163.204.146 184.154.208.35 108.163.204.149 
96.127.190.6 69.175.69.91 184.154.58.226 108.163.228.173 108.178.24.173 
108.178.24.178 96.127.176.254 198.143.161.18 184.154.48.174 198.143.161.20 
184.154.58.229 108.163.220.51 96.127.176.251 108.163.220.50 108.178.24.170 
108.163.220.53 198.143.161.22 184.154.208.38 184.154.48.170 184.154.58.228 
108.178.24.172 198.143.161.14 108.178.24.179 198.143.161.19 108.163.204.147 
198.143.161.26 96.127.190.3

If your getaddrinfo returns only the first address, it is busted.
Perhaps this is controlled via /etc/hosts.conf:

http://www.linfo.org/etc_host_conf.html

/etc/hosts.conf:
multi on

> That said.  Since the unit has been updated, but not rebooted, I may need to
> reboot to get the kernel fix.  Ubuntu does, at least, backport fixes.

The getaddrinfo issue is not resolved via a kernel fix, it is
addressed via a glibc fix.

-- 
Viktor.

Re: A bug, maybe?

2016-02-20 Thread Curtis Maurand 



On 2/20/2016 12:17 PM, Viktor Dukhovni wrote:

On Sat, Feb 20, 2016 at 11:40:09AM -0500, Curtis Maurand wrote:


i just sent myself a test message from the client's system.  Here is what I
got.  I immediately ran the lookups using dig.  postfix can't seem to
resolve things properly.  Running Ubuntu Server 14.04 LTS with ispconfig
installed.  I'm using powerdns with powerdns recursor.  resolv.conf points
to the localhost's external ip address.  This is sort of annoying.  I really
don't want to open up the server's to misconfigured system as that increases
the amount of spam dramatically.

Do keep in mind that on Ubuntu systems Postfix tends to have many
services in master.cf chooted by default, the chroot jail may have
a different /etc/resolv.conf, and may have different copies of
various dynamically loaded nss modules.

Do disable chroot for "smtpd" if enabled, and do test your
getaddrinfo() implementation.


Nothing is chrooted.  resolv.conf is world readable.  Wietse's program 
returns a valid address.  It might not match the reverse, but it did 
return an address.

# ./getaddr delivery.mailspamprotection.com
Hostname:   delivery.mailspamprotection.com
Addresses:  108.163.228.171

That said.  Since the unit has been updated, but not rebooted, I may 
need to reboot to get the kernel fix.  Ubuntu does, at least, backport 
fixes.





--
Curtis Maurand
cur...@maurand.com 
207-252-7748

Re: A bug, maybe?

2016-02-20 Thread Viktor Dukhovni 
On Sat, Feb 20, 2016 at 11:40:09AM -0500, Curtis Maurand wrote:

> i just sent myself a test message from the client's system.  Here is what I
> got.  I immediately ran the lookups using dig.  postfix can't seem to
> resolve things properly.  Running Ubuntu Server 14.04 LTS with ispconfig
> installed.  I'm using powerdns with powerdns recursor.  resolv.conf points
> to the localhost's external ip address.  This is sort of annoying.  I really
> don't want to open up the server's to misconfigured system as that increases
> the amount of spam dramatically.

Do keep in mind that on Ubuntu systems Postfix tends to have many
services in master.cf chooted by default, the chroot jail may have
a different /etc/resolv.conf, and may have different copies of
various dynamically loaded nss modules.

Do disable chroot for "smtpd" if enabled, and do test your
getaddrinfo() implementation.

-- 
Viktor.

Re: A bug, maybe?

2016-02-20 Thread Wietse Venema 
Curtis Maurand:
> Feb 19 16:30:29 ispconfig postfix/smtpd[18437]: warning: hostname
> delivery.mailspamprotection.com does not resolve to address
> 108.163.243.188

The problem of testing with nslookup, dig, etc., is that they don't
use the getaddrinfo() system library function that Postfix uses to
look up the remote SMTP client IP address. This uses nsswitch, which
uses nscd or whatever it is called today.

You can test your getaddrinfo() system library function with the
attached test program.

But you will never be able to reproduce the conditions of Feb 19 16:30:29.

BTW This week there was a major bugfix for getaddrinfo() on Linux
systems. So yours has probably been updated.

Wietse

 /*
  * getaddrinfo(3) (name->address lookup) tester.
  * 
  * Compile with:
  * 
  * cc -o getaddrinfo getaddrinfo.c (BSD, Linux)
  * 
  * cc -o getaddrinfo getaddrinfo.c -lsocket -lnsl (SunOS 5.x)
  * 
  * Run as: getaddrinfo hostname
  * 
  * Author: Wietse Venema, Eindhoven University of Technology, The Netherlands.
  * 
  * Author: Wietse Venema, IBM T.J. Watson Research, USA.
  */
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

int main(int argc, char **argv)
{
charhostbuf[NI_MAXHOST];/* XXX */
struct addrinfo hints;
struct addrinfo *res0;
struct addrinfo *res;
const char *addr;
int err;

#define NO_SERVICE ((char *) 0)

if (argc != 2) {
fprintf(stderr, "usage: %s hostname\n", argv[0]);
exit(1);
}
memset((char *) , 0, sizeof(hints));
hints.ai_family = PF_UNSPEC;
hints.ai_flags = AI_CANONNAME;
hints.ai_socktype = SOCK_STREAM;
if ((err = getaddrinfo(argv[1], NO_SERVICE, , )) != 0) {
fprintf(stderr, "host %s not found: %s\n", argv[1], gai_strerror(err));
exit(1);
}
printf("Hostname:\t%s\n", res0->ai_canonname);
printf("Addresses:\t");
for (res = res0; res != 0; res = res->ai_next) {
addr = (res->ai_family == AF_INET ?
(char *) &((struct sockaddr_in *) res->ai_addr)->sin_addr :
(char *) &((struct sockaddr_in6 *) res->ai_addr)->sin6_addr);
if (inet_ntop(res->ai_family, addr, hostbuf, sizeof(hostbuf)) == 0) {
perror("inet_ntop:");
exit(1);
}
printf("%s ", hostbuf);
}
printf("\n");
freeaddrinfo(res0);
exit(0);
}

Re: A bug, maybe?

2016-02-20 Thread Curtis Maurand 



On 2/20/2016 11:26 AM, Curtis Maurand wrote:



On 2/20/2016 11:12 AM, Christian Kivalo wrote:

On 2016-02-20 16:45, Curtis Maurand wrote:

Not sure if I found something or not.  A client tried to send email
to one of my other addresses.  The requisite portion of the main.cf
follows at the end of the message.  The logs are telling me:

Feb 19 16:30:29 ispconfig postfix/smtpd[18437]: warning: hostname
delivery.mailspamprotection.com does not resolve to address
108.163.243.188
Feb 19 16:30:29 ispconfig postfix/smtpd[18437]: connect from
unknown[108.163.243.188]
Feb 19 16:30:29 ispconfig postfix/smtpd[18437]: NOQUEUE: reject: RCPT
from unknown[108.163.243.188]: 450 4.7.1 Client host rejected: cannot
find your hostname, [108.163.243.188];
from= to= proto=ESMTP
helo=


Have you had dns lookup problems? This is a temporary error and the 
client should retry delivery




450 4.7.1 Client host rejected: cannot find your hostname,
[108.163.243.188]:
retry timeout exceeded

the original message was sent on the 15th.  the return bounce on the 
19th.  I haven't rebooted or restarted services on that machine and 
all of the included lookups for this mail message were performed on 
the same machine this morning.


i just sent myself a test message from the client's system.  Here is 
what I got.  I immediately ran the lookups using dig.  postfix can't 
seem to resolve things properly.  Running Ubuntu Server 14.04 LTS with 
ispconfig installed.  I'm using powerdns with powerdns recursor.  
resolv.conf points to the localhost's external ip address.  This is sort 
of annoying.  I really don't want to open up the server's to 
misconfigured system as that increases the amount of spam dramatically.


Feb 20 11:31:45 ispconfig postfix/smtpd[16013]: warning: hostname 
delivery.mailspamprotection.com does not resolve to address 108.163.220.52
Feb 20 11:31:45 ispconfig postfix/smtpd[16013]: connect from 
unknown[108.163.220.52]
Feb 20 11:31:45 ispconfig postfix/smtpd[16013]: NOQUEUE: reject: RCPT 
from unknown[108.163.220.52]: 450 4.7.1 Client host rejected: cannot 
find your hostname, [108.163.220.52]; from= 
to= proto=ESMTP helo=
Feb 20 11:31:45 ispconfig postfix/smtpd[16013]: disconnect from 
unknown[108.163.220.52]

Feb 20 11:32:01 ispconfig postfix/smtpd[16013]: connect from localhost[::1]
Feb 20 11:32:01 ispconfig postfix/smtpd[16013]: lost connection after 
CONNECT from localhost[::1]
Feb 20 11:32:01 ispconfig postfix/smtpd[16013]: disconnect from 
localhost[::1]


root@ispconfig:/var/www/webmail.xyonet.com/web# dig 
delivery.mailspamprotection.com |grep 108.163.220

delivery.mailspamprotection.com. 30 IN  A 108.163.220.50
delivery.mailspamprotection.com. 30 IN  A 108.163.220.51
delivery.mailspamprotection.com. 30 IN  A 108.163.220.53
delivery.mailspamprotection.com. 30 IN  A 108.163.220.54
delivery.mailspamprotection.com. 30 IN  A 108.163.220.52
root@ispconfig:/var/www/webmail.xyonet.com/web# dig ptr 
52.220.163.108.in-addr.arpa


; <<>> DiG 9.9.5-3ubuntu0.7-Ubuntu <<>> ptr 52.220.163.108.in-addr.arpa
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32216
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

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

;; ANSWER SECTION:
52.220.163.108.in-addr.arpa. 3495 INPTR delivery.mailspamprotection.com.





--
Curtis Maurand
cur...@maurand.com 
207-252-7748


--
Curtis Maurand
cur...@maurand.com 
207-252-7748

Re: A bug, maybe?

2016-02-20 Thread Curtis Maurand 



On 2/20/2016 11:12 AM, Christian Kivalo wrote:

On 2016-02-20 16:45, Curtis Maurand wrote:

Not sure if I found something or not.  A client tried to send email
to one of my other addresses.  The requisite portion of the main.cf
follows at the end of the message.  The logs are telling me:

Feb 19 16:30:29 ispconfig postfix/smtpd[18437]: warning: hostname
delivery.mailspamprotection.com does not resolve to address
108.163.243.188
Feb 19 16:30:29 ispconfig postfix/smtpd[18437]: connect from
unknown[108.163.243.188]
Feb 19 16:30:29 ispconfig postfix/smtpd[18437]: NOQUEUE: reject: RCPT
from unknown[108.163.243.188]: 450 4.7.1 Client host rejected: cannot
find your hostname, [108.163.243.188];
from= to= proto=ESMTP
helo=


Have you had dns lookup problems? This is a temporary error and the 
client should retry delivery




450 4.7.1 Client host rejected: cannot find your hostname,
[108.163.243.188]:
retry timeout exceeded

the original message was sent on the 15th.  the return bounce on the 
19th.  I haven't rebooted or restarted services on that  machine and all 
of the included lookups for this mail message were performed on the same 
machine this morning.



--
Curtis Maurand
cur...@maurand.com 
207-252-7748

Re: A bug, maybe?

2016-02-20 Thread Christian Kivalo 

On 2016-02-20 16:45, Curtis Maurand wrote:

Not sure if I found something or not.  A client tried to send email
to one of my other addresses.  The requisite portion of the main.cf
follows at the end of the message.  The logs are telling me:

Feb 19 16:30:29 ispconfig postfix/smtpd[18437]: warning: hostname
delivery.mailspamprotection.com does not resolve to address
108.163.243.188
Feb 19 16:30:29 ispconfig postfix/smtpd[18437]: connect from
unknown[108.163.243.188]
Feb 19 16:30:29 ispconfig postfix/smtpd[18437]: NOQUEUE: reject: RCPT
from unknown[108.163.243.188]: 450 4.7.1 Client host rejected: cannot
find your hostname, [108.163.243.188];
from= to= proto=ESMTP
helo=


Have you had dns lookup problems? This is a temporary error and the 
client should retry delivery



Feb 19 16:30:30 ispconfig postfix/smtpd[18437]: disconnect from
unknown[108.163.243.188]

deliver.mailspamprotection.com resolves to a lot of addresses (and
this is a partial list):

dig delivery.mailspamprotection.com |grep 108.163.243
delivery.mailspamprotection.com. 30 IN  A   108.163.243.188
delivery.mailspamprotection.com. 30 IN  A   108.163.243.187
delivery.mailspamprotection.com. 30 IN  A   108.163.243.189
delivery.mailspamprotection.com. 30 IN  A   108.163.243.190
delivery.mailspamprotection.com. 30 IN  A   108.163.243.186

and

;188.243.163.108.in-addr.arpa.  IN  PTR

;; ANSWER SECTION:
188.243.163.108.in-addr.arpa. 3600 IN   PTR
delivery.mailspamprotection.com.

given such a round robin setup, does postfix account for this when
performing it's hostname lookup?  This email should not have been
rejected for any kind of ip mismatch.  Forward, reverse and helo all
match.

Thanks,
Curtis

smtpd_sender_restrictions =
  check_sender_access regexp:/etc/postfix/tag_as_originating.re
  permit_mynetworks,
  permit_sasl_authenticated,
  check_recipient_access
mysql:/etc/postfix/mysql-virtual_recipient.cf,
  check_sender_access mysql:/etc/postfix/mysql-virtual_sender.cf,
regexp:/etc/postfix/tag_as_foreign.re
  reject_invalid_hostname,
  reject_unknown_sender_domain,
  reject_unknown_recipient_domain,
  reject_unauth_pipelining,
  reject_rbl_client bl.spamcop.net,
  reject_rbl_client zen.spamhaus.org,
  reject_rbl_client b.barracudacentral.org

smtpd_client_restrictions =
  permit_mynetworks,
  permit_sasl_authenticated,
  check_client_access
  mysql:/etc/postfix/mysql-virtual_client.cf,
  reject_unknown_client,
this restriction causes the reject, see 
http://www.postfix.org/postconf.5.html#reject_unknown_client_hostname


reject_unknown_client_hostname (with Postfix < 2.3: 
reject_unknown_client)
Reject the request when 1) the client IP address->name mapping fails, 2) 
the name->address mapping fails, or 3) the name->address mapping does 
not match the client IP address.
This is a stronger restriction than the 
reject_unknown_reverse_client_hostname feature, which triggers only 
under condition 1) above.
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.


reject_unknown_reverse_client_hostname is considered the safer 
alternative but in your case maybe removing it altogether allows more 
legitimate mail through.



  reject_invalid_hostname,
  reject_unknown_sender_domain,
  reject_unknown_recipient_domain,
  reject_unauth_pipelining,
  reject_unauth_destination,
  reject_rbl_client bl.spamcop.net,
  reject_rbl_client zen.spamhaus.org,
  reject_rbl_client b.barracudacentral.org

--
Curtis Maurand
cur...@maurand.com
207-252-7748


--
 Christian Kivalo

Re: A bug, maybe?

2016-02-20 Thread Viktor Dukhovni 
On Sat, Feb 20, 2016 at 10:45:42AM -0500, Curtis Maurand wrote:

> Feb 19 16:30:29 ispconfig postfix/smtpd[18437]:
> warning: hostname delivery.mailspamprotection.com
> does not resolve to address 108.163.243.188
> Feb 19 16:30:29 ispconfig postfix/smtpd[18437]:
> connect from unknown[108.163.243.188]
> Feb 19 16:30:29 ispconfig postfix/smtpd[18437]:
> NOQUEUE: reject: RCPT from unknown[108.163.243.188]:
> 450 4.7.1 Client host rejected: cannot find your hostname, 
> [108.163.243.188];
> from= to= proto=ESMTP
> helo=

Error "450" is a temporary error, the DNS lookup temp failed, stuff
happens.

> deliver.mailspamprotection.com resolves to a lot of addresses (and this is a
> partial list):
> 
> dig delivery.mailspamprotection.com |grep 108.163.243
> delivery.mailspamprotection.com. 30 IN  A 108.163.243.188
> delivery.mailspamprotection.com. 30 IN  A 108.163.243.187
> delivery.mailspamprotection.com. 30 IN  A 108.163.243.189
> delivery.mailspamprotection.com. 30 IN  A 108.163.243.190
> delivery.mailspamprotection.com. 30 IN  A 108.163.243.186

Yes, it resolves to 81 addresses at present, that's more typical
of a spam-sending system than an anti-spam system.  Perhaps
mailspamprotection means protection of spam, rather than protection
from spam?

The large DNS packet size needed to return the PTR record in question
can be contributing factor to interoperability issues.  You also
should check that the getaddrinfo(3) C-library function on your
system returns all 81 addresses that you might see via dig(1).

> given such a round robin setup, does postfix account for this when
> performing it's hostname lookup?

Yes, but the C-library and your resolver need to return the relevant
addresses.

> This email should not have been rejected
> for any kind of ip mismatch.  Forward, reverse and helo all match.

They do now, they did not then.

-- 
Viktor.