Re: postfix PTR Lookup internals

2018-05-14 Thread Vivaldi Vivaldi
My problem is solved. Solution in one line *cp -vl /usr/lib64/libnss_* /var/spool/postfix/lib64* Cheers! 2018-05-15 0:46 GMT+03:00 Vivaldi Vivaldi : > Well spotted again! > Everything resolves as expected after chroot is disabled. > So, I'm digging that way. > Thanks for

OT: Risks & mitigations of allowing an external sender to send to us (with sender 'same domain' as us)

2018-05-14 Thread Roger Goh
There is an external app server (that is our service provider) that we want them to blast emails to a team/department in our organization (email domain @ xyz.com) but these emails will have the sender to be in same domain as us ie @xyz.com . What are the risks of permitting such bypass (ie

Question regarding OpenDKIM milter with Postfix 3.1.0

2018-05-14 Thread J Doe
Hi, I apologize for asking a question that is only tangentially related to Postfix, however the OpenDKIM mailing lists do not appear to be accessible. I am using Postfix 3.1.0 and OpenDKIM 2.10.3. Upon reboot of my server, I noticed “normal” stats regarding caching (which I have enabled in

Re: postfix PTR Lookup internals

2018-05-14 Thread Vivaldi Vivaldi
Well spotted again! Everything resolves as expected after chroot is disabled. So, I'm digging that way. Thanks for your help, regards! 2018-05-15 0:17 GMT+03:00 Noel Jones : > The chroot details are different for each operating system. If you > installed postfix from a

Re: postfix PTR Lookup internals

2018-05-14 Thread Noel Jones
The chroot details are different for each operating system. If you installed postfix from a package for your OS, often a script is included with the package to build the chroot environment. If you didn't install from a package, or you did but the supplied script didn't work, you may get better

Re: postfix PTR Lookup internals

2018-05-14 Thread Vivaldi Vivaldi
I've already found http://www.postfix.org/BASIC_CONFIGURATION_README.html#chroot_setup, but may be more detailed description exists, I hope. 2018-05-15 0:03 GMT+03:00 Vivaldi Vivaldi : > > chroot environment is incomplete > > Where can I find complete example of postfix

Re: postfix PTR Lookup internals

2018-05-14 Thread Vivaldi Vivaldi
> chroot environment is incomplete Where can I find complete example of postfix chroot environment? 2018-05-15 0:00 GMT+03:00 Vivaldi Vivaldi : > Yes, your are right postfix chained in the chroot environment for security > reasons as usual. > Though, at another VPS running

Re: postfix PTR Lookup internals

2018-05-14 Thread Vivaldi Vivaldi
Yes, your are right postfix chained in the chroot environment for security reasons as usual. Though, at another VPS running Debian 7 and Postfix 2.9.6 also chrooted everithing, works perfect as for reverse lookup. So I get confused a lot with that "quirk" 2018-05-14 23:46 GMT+03:00 Noel Jones

Re: postfix PTR Lookup internals

2018-05-14 Thread Noel Jones
On 5/14/2018 3:19 PM, Vivaldi Vivaldi wrote: > Hello everybody! > ** > > I see following /maillog/ records when new mail comes to server > > |connect from unknown [209.85.223.195] client=unknown[209.85.223.195] | > > But that IP address is GMail IP and it has valid PTR-record which > points to

postfix PTR Lookup internals

2018-05-14 Thread Vivaldi Vivaldi
Hello everybody! I see following *maillog* records when new mail comes to server connect from unknown [209.85.223.195] client=unknown[209.85.223.195] But that IP address is GMail IP and it has valid PTR-record which points to *mail-io0-f195.google.com * My

Re: Lookup tables

2018-05-14 Thread Noel Jones
On 5/14/2018 1:46 PM, jack wrote: > > On 14/05/2018 18:58, Viktor Dukhovni wrote: >> >> >> Look for "HOST NAME/ADDRESS PATTERNS" in >> http://www.postfix.org/access.5.html >> >> The http://www.postfix.org/postconf.5.html#check_client_access >> docs point >> you at access(5), so this is not

Re: Lookup tables

2018-05-14 Thread Viktor Dukhovni
> On May 14, 2018, at 2:46 PM, jack wrote: > > The fact which I think may be undocumented is that postfix (but not > postmap) performs iterative prefix queries, when (and only when?) the > table-type is indexed. This is basic logic, support for multi-line header/body

Re: Lookup tables

2018-05-14 Thread jack
On 14/05/2018 18:58, Viktor Dukhovni wrote: Look for "HOST NAME/ADDRESS PATTERNS" in http://www.postfix.org/access.5.html The http://www.postfix.org/postconf.5.html#check_client_access docs point you at access(5), so this is not exactly hiding... Thank you Viktor, I am familiar with those

Re: Lookup tables

2018-05-14 Thread Viktor Dukhovni
> On May 14, 2018, at 1:54 PM, jack wrote: > >> Postfix will query hash (btreem, dbm, lmdb, ldap, etc.) table >> multiple times, first with the full IP address and then with prefixes >> of the IP address. With your example of 5.188.9.2 the queries would >> be: >> >>

Re: Lookup tables

2018-05-14 Thread jack
On 14/05/2018 12:13, Wietse Venema wrote: > > Postfix will query hash (btreem, dbm, lmdb, ldap, etc.) table > multiple times, first with the full IP address and then with prefixes > of the IP address. With your example of 5.188.9.2 the queries would > be: > > 5.188.9.2 > 5.188.9 > >

Re: can 554 bounce be made soft, for retries?

2018-05-14 Thread Wietse Venema
tomww: > Hi, > > is it possible to config the sending postfix to retry the delivery > to one specific target mailserver as if it was a soft-bounce? > Unfortunatly the target shows very often a full mailbox. > > May 14 15:26:21 mailrouter postfix/smtp[8044]: [ID 197553 mail.info] > 2B6FC248FC:

can 554 bounce be made soft, for retries?

2018-05-14 Thread tomww
Hi, is it possible to config the sending postfix to retry the delivery to one specific target mailserver as if it was a soft-bounce? Unfortunatly the target shows very often a full mailbox. May 14 15:26:21 mailrouter postfix/smtp[8044]: [ID 197553 mail.info] 2B6FC248FC:

Re: Lookup tables

2018-05-14 Thread jack
Mike, I had: # postconf smtpd_client_restrictions smtpd_client_restrictions = reject_unknown_reverse_client_hostname, check_client_access hash:/etc/postfix/client_access, permit_sasl_authenticated On 14/05/2018 12:13, Wietse Venema wrote: > jack: >> Hi, >> >> In the online documentation for

Re: Lookup tables

2018-05-14 Thread jack
# postconf smtpd_client_restrictions smtpd_client_restrictions = reject_unknown_reverse_client_hostname, check_client_access hash:/etc/postfix/client_access, permit_sasl_authenticated On 14/05/2018 12:00, Mike Guelfi wrote: > postmap is a lookup management tool; doing a query on an IP in a subnet

Re: Lookup tables

2018-05-14 Thread Wietse Venema
jack: > Hi, > > In the online documentation for access tables > (http://www.postfix.org/access.5.html), it says: > > Subnetworks are matched by repeatedly truncating > the last ".octet" from the remote IPv4 host address > string until a match is

Re: Lookup tables

2018-05-14 Thread Mike Guelfi
postmap is a lookup management tool; doing a query on an IP in a subnet isn't going to succeed. You probably just forgot to enable client_access or reload postfix What does this return? # postconf smtpd_client_restrictions Default is: smtpd_client_restrictions = enabled would be:

Re: Lookup tables

2018-05-14 Thread jack
Sorry - I should have said: Postfix 2.11.3, running on Debian Jessie. Also, I ran these tests using postmap when it became apparent to me that postfix itself was not matching address prefixes in hash tables. On 14/05/2018 11:18, jack wrote: > Hi, > > In the online documentation for access

Lookup tables

2018-05-14 Thread jack
Hi, In the online documentation for access tables (http://www.postfix.org/access.5.html), it says: Subnetworks are matched by repeatedly truncating the last ".octet" from the remote IPv4 host address string until a match is found in the access

Re: real life reasons not to use reject_unknown_client_hostname

2018-05-14 Thread Vlad K
On 2018-05-13 10:05, Dominic Raferd wrote: What do people think about reject_unknown_reverse_client_hostname? I use this presuming it to be safe, and it blocks lots of stuff. That's what we use, and from what I've seen it is effective, almost all of the senders with no rDNS are from