Re: using a non fully qualified host name as relayhost
On 2014-12-03 17:52, Viktor Dukhovni wrote: On Wed, Dec 03, 2014 at 04:55:47PM +, Viktor Dukhovni wrote: On Wed, Dec 03, 2014 at 04:36:12PM +, James Bailey wrote: is it possible to use a non fully qualified host name as relayhost? Not by default. And it is generally not a good idea to change this. However, if you replace the relayhost setting with: # Default empty value # relayhost = default_transport = nondns:[relayhost] Oh, and if relay_domains is not empty, also: relay_transport = nondns:[relayhost] Keep in mind that the default value of relay_domains is $mydestination, and that by default parent_domain_matches_subdomains includes relay_domains. The upshot of which is that all sub-domains of domains listed in $mydestination are implicitly relay_domains. I generally recommend: # Empty, or otherwise explicit list of domains. # relay_domains = # Only access(5) maps use dot-less parent-domain matching # parent_domain_matches_subdomains = smtpd_access_maps Many thanks Victor, The problem is non trivial with the hosts named $host.hosts.example.com but the working CNAMES are smtp_relay.$dc.$env.$division.example.com normally I would manage main.cf with Puppet and an ENC, unfortunately the client a large financial software client doesn't yet use such tools and since it is also a PCI/DSS environment, such a tools is unlikely to be approved in the few months I am here. The files are deployed by Perl scripts, so I guess it time to roll back some of the changes I made there and add a few new ones Regards Jim
Postfix relaying non authenticated virtual user's mails in local
test testovich
Problem with reject_rbl_client when a wildcard entry for mydomain exists
Hi, We experience problems when using reject_rbl_client if a wildcard entry for mydomain exists. It appears that a DNS lookup is first made with [ip].[rbl] and than with [ip].[rbl].[mydomain] if no entry has been found. This leads to false positives if a DNS wildcard entry for xxx.[mydomain] exists. Example: 18:19:10.976007 mail.mydomain.com.17363 postfix.local-prod.local.domain: 9896+ PTR? 21.17.227.212.in-addr.arpa. (44) 18:19:11.004248 postfix.local-prod.local.domain mail.mydomain.com.17363: 9896 1/0/0 PTR mout.gmx.net. (70) 18:19:11.004394 mail.mydomain.com.20184 postfix.local-prod.local.domain: 58856+ A? mout.gmx.net. (30) 18:19:11.004725 postfix.local-prod.local.domain mail.mydomain.com.20184: 58856 6/0/0 A mout.gmx.net, A mout.gmx.net, A[|domain] (DF) 18:19:11.354892 mail.mydomain.com.35558 postfix.local-prod.local.domain: 50868+ A? 21.17.227.212.zen.spamhaus.org. (48) 18:19:11.542972 postfix.local-prod.local.domain mail.mydomain.com.35558: 50868 NXDomain 0/1/0 (112) (DF) 18:19:11.543002 mail.mydomain.com.2259 postfix.local-prod.local.domain: 11912+ A? 21.17.227.212.zen.spamhaus.org.mydomain.com. (60) - If a A record for *.mydomain.com exists this leads to a false positive 18:19:11.643002 postfix.local-prod.local.domain mail.mydomain.com.2259: 11912 NXDomain 0/1/0 (121) (DF) 18:19:11.643030 mail.mydomain.com.35352 postfix.local-prod.local.domain: 32908+ A? 21.17.227.212.zen.spamhaus.org. (48) 18:19:11.643385 postfix.local-prod.local.domain mail.mydomain.com.35352: 32908 NXDomain 0/1/0 (112) (DF) 18:19:11.643475 mail.mydomain.com.44535 postfix.local-prod.local.domain: 10940+ MX? gmx.ch. (24) 18:19:11.673154 postfix.local-prod.local.domain mail.mydomain.com.44535: 10940 2/0/4 MX mx00.emig.gmx.net. 10, MX[|domain] (DF) 18:19:11.904275 mail.mydomain.com.5803 postfix.local-prod.local.domain: 29132+ PTR? 100.10.168.192.in-addr.arpa. (45) 18:19:11.904731 postfix.local-prod.local.domain mail.mydomain.com.5803: 29132* 1/0/0 PTR[|domain] (DF) 18:19:11.905085 mail.mydomain.com.39746 postfix.local-prod.local.domain: 36015+ PTR? 18.15.227.212.in-addr.arpa. (44) 18:19:11.949389 postfix.local-prod.local.domain mail.mydomain.com.39746: 36015 1/0/0 PTR mout.gmx.net. (70) (DF) 18:19:11.949511 mail.mydomain.com.40551 postfix.local-prod.local.domain: 57004+ PTR? 22.17.227.212.in-addr.arpa. (44) 18:19:11.949858 postfix.local-prod.local.domain mail.mydomain.com.40551: 57004 1/0/0 PTR mout.gmx.net. (70) (DF) cheers, Stefan
Re: Problem with reject_rbl_client when a wildcard entry for mydomain exists
s.sm...@gmx.ch: Hi, We experience problems when using reject_rbl_client if a wildcard entry for mydomain exists. It appears that a DNS lookup is first made with [ip].[rbl] and than with [ip].[rbl].[mydomain] if no entry has been found. This leads to false positives if a DNS wildcard entry for xxx.[mydomain] exists. Postfix does not enable RES_DNSRCH or RES_DEFNAMES for DNSBL lookups. I suspect that you have some too-helpful DNS proxy. Wietse
Re: Problem with reject_rbl_client when a wildcard entry for mydomain exists
s.small: It appears that a DNS lookup is first made with [ip].[rbl] and than with [ip].[rbl].[mydomain] if no entry has been found. general advise: check your /etc/resolv.conf usually there is no need for other lines then nameserver $NAMESERVER_IP especially check if searchdomain is present and needed and should be removed. If you run any service chroot don't forget these copies. Andrreas
Re: Problem with reject_rbl_client when a wildcard entry for mydomain exists
On Thu, Dec 04, 2014 at 07:31:42PM +0100, A. Schulze wrote: It appears that a DNS lookup is first made with [ip].[rbl] and than with [ip].[rbl].[mydomain] if no entry has been found. Postfix explicitly disables RES_DNSRCH | RES_DEFNAMES in the resolver options when doing MX, rbl and other lookups where these would be inappropriate. If someone maintaining libresolv or libc helpfully broke the interface, then complain to your OS distribution maintainer. general advice: check your /etc/resolv.conf usually there is no need for other lines then nameserver $NAMESERVER_IP especially check if searchdomain is present and needed and should be removed. This advice is not right, Postfix works (on platforms with a libresolv that has not been improved) even when default domains and search paths are specified in libresolv. -- Viktor.
Re: Problem with reject_rbl_client when a wildcard entry for mydomain exists
Viktor Dukhovni: general advice: check your /etc/resolv.conf usually there is no need for other lines then nameserver $NAMESERVER_IP especially check if searchdomain is present and needed and should be removed. This advice is not right, Postfix works ... Yes, BUT: I had not only postfix in mind. Other server software does not so many things right as postfix does. For that reason general ... A server should generally be well configured to use only fully qualified domainnames. As a consequence a server does not need a searchdomain in /etc/resolv.conf and therefor it could be removed. I do so for many years and saw some strange things went away. That's simply my experience running numerous different server over the years. Andreas
Re: Problem with reject_rbl_client when a wildcard entry for mydomain exists
A. Schulze: Viktor Dukhovni: general advice: check your /etc/resolv.conf usually there is no need for other lines then nameserver $NAMESERVER_IP especially check if searchdomain is present and needed and should be removed. This advice is not right, Postfix works ... Yes, BUT: I had not only postfix in mind. Other server software does not so many things right as postfix does. For that reason general ... A server should generally be well configured to use only fully qualified domainnames. As a consequence a server does not need a searchdomain in /etc/resolv.conf and therefor it could be removed. I do so for many years and saw some strange things went away. That's simply my experience running numerous different server over the years. If some vendor appends domains despite Postfix turning that off, please file a complaint. That vendor is not helping. Wietse
email header contains IP address of sending client
When I send email via my Postfix, the header actually contains the IP address of my laptop. Such as 192.168.1.113 [12.34.56.78]) in the example below: Received: from mail.origin.com (mail.origin.com [65.254.242.180]) by mail.destination.com (Postfix) with ESMTPS id 31A1B66 for u...@destination.com; Thu, 4 Dec 2014 21:00:36 +0100 (CET) Received: from [192.168.1.113] (unknown [12.34.56.78]) by mail.origin.com (Postfix) with ESMTPSA id 08AE908 for u...@destination.com; Thu, 4 Dec 2014 21:00:36 +0100 (CET) Is it possible to disable this, or would that constitute breaking standards ? Is there any use in exposing my laptop IP address? PS: I understand that in the above example, 192.168.1.113 is a non-routable IP. But it could be any IP, depending on the client. thanks, Martin
Re: email header contains IP address of sending client
On 12/04/2014 08:20 PM, Martin Vegter wrote: When I send email via my Postfix, the header actually contains the IP address of my laptop. Such as 192.168.1.113 [12.34.56.78]) in the example below: Received: from mail.origin.com (mail.origin.com [65.254.242.180]) by mail.destination.com (Postfix) with ESMTPS id 31A1B66 for u...@destination.com; Thu, 4 Dec 2014 21:00:36 +0100 (CET) Received: from [192.168.1.113] (unknown [12.34.56.78]) by mail.origin.com (Postfix) with ESMTPSA id 08AE908 for u...@destination.com; Thu, 4 Dec 2014 21:00:36 +0100 (CET) Is it possible to disable this, or would that constitute breaking standards ? Is there any use in exposing my laptop IP address? PS: I understand that in the above example, 192.168.1.113 is a non-routable IP. But it could be any IP, depending on the client. See `man header_checks | less +/IGNORE`. That's the way to remove uninteresting headers. Regards, Pascal -- The trapper recommends today: c01dcofe.1433...@localdomain.org
Re: email header contains IP address of sending client
Am 04.12.2014 um 21:20 schrieb Martin Vegter: When I send email via my Postfix, the header actually contains the IP address of my laptop. Such as 192.168.1.113 [12.34.56.78]) in the example below: Received: from mail.origin.com (mail.origin.com [65.254.242.180]) by mail.destination.com (Postfix) with ESMTPS id 31A1B66 for u...@destination.com; Thu, 4 Dec 2014 21:00:36 +0100 (CET) Received: from [192.168.1.113] (unknown [12.34.56.78]) by mail.origin.com (Postfix) with ESMTPSA id 08AE908 for u...@destination.com; Thu, 4 Dec 2014 21:00:36 +0100 (CET) your client conntected to the SMTP, so it is logged and a received heaer added, becasue, well postfix received the mail from tehre Is it possible to disable this, or would that constitute breaking standards? Is there any use in exposing my laptop IP address? postfix don't care if it is your notebook it add a received header for *any* client PS: I understand that in the above example, 192.168.1.113 is a non-routable IP. But it could be any IP, depending on the client and you typically want to know that IP as sysadmin others don't care at all if you don't want to expose it configure postfix that way and the only point where it makes sense is in the smtp-*client* realy mail outside http://www.postfix.org/postconf.5.html#smtp_header_checks /^Received: from .* \[192\.168\./ IGNORE
Re: email header contains IP address of sending client
On 12/4/2014 2:20 PM, Martin Vegter wrote: When I send email via my Postfix, the header actually contains the IP address of my laptop. Such as 192.168.1.113 [12.34.56.78]) in the example below: Received: from mail.origin.com (mail.origin.com [65.254.242.180]) by mail.destination.com (Postfix) with ESMTPS id 31A1B66 for u...@destination.com; Thu, 4 Dec 2014 21:00:36 +0100 (CET) Received: from [192.168.1.113] (unknown [12.34.56.78]) by mail.origin.com (Postfix) with ESMTPSA id 08AE908 for u...@destination.com; Thu, 4 Dec 2014 21:00:36 +0100 (CET) Is it possible to disable this, or would that constitute breaking standards ? Is there any use in exposing my laptop IP address? This is considered important debugging information, and not particularly useful information to an attacker. You can remove or alter the line with a smtp_header_checks rule, but be *very careful* not to alter unrelated headers, or Received: headers that aren't yours. Construct your regexp carefully. Also be aware (at least in the past) some spam appliances consider a missing Received: header as a spam sign, so removing the header may affect your mail delivery to a few sites. -- Noel Jones
Re: email header contains IP address of sending client
Pascal Volk: On 12/04/2014 08:20 PM, Martin Vegter wrote: When I send email via my Postfix, the header actually contains the IP address of my laptop. Such as 192.168.1.113 [12.34.56.78]) in the example below: Received: from mail.origin.com (mail.origin.com [65.254.242.180]) by mail.destination.com (Postfix) with ESMTPS id 31A1B66 for u...@destination.com; Thu, 4 Dec 2014 21:00:36 +0100 (CET) Received: from [192.168.1.113] (unknown [12.34.56.78]) by mail.origin.com (Postfix) with ESMTPSA id 08AE908 for u...@destination.com; Thu, 4 Dec 2014 21:00:36 +0100 (CET) Is it possible to disable this, or would that constitute breaking standards ? Is there any use in exposing my laptop IP address? PS: I understand that in the above example, 192.168.1.113 is a non-routable IP. But it could be any IP, depending on the client. See `man header_checks | less +/IGNORE`. That's the way to remove uninteresting headers. Remove only your own Received: header: /etc/postfix/main.cf: header_checks = pcre:/etc/postfix/header_checks /etc/postfix/header_checks /^Received: from \[192\.168\..+ by mail\.origin\.com / IGNORE You can use regexp: instead of pcre: with the above pattern. Wietse
Re: email header contains IP address of sending client
On 12/4/2014 2:29 PM, li...@rhsoft.net wrote: if you don't want to expose it configure postfix that way and the only point where it makes sense is in the smtp-*client* realy mail outside Yes. http://www.postfix.org/postconf.5.html#smtp_header_checks /^Received: from .* \[192\.168\./ IGNORE Your example expression is overly broad, and will likely remove headers that shouldn't be removed. Your example expression is overly narrow, and will not remove headers when eg. the client is on an outside network using AUTH. Better (untested) /^Received: .*by mail\.origin\.com \(Postfix\) with ESMTPSA/ IGNORE the OP may need two expressions if some clients submit within $mynetworks without using AUTH. -- Noel Jones
Re: email header contains IP address of sending client
On 12/4/2014 2:20 PM, Martin Vegter wrote: When I send email via my Postfix, the header actually contains the IP address of my laptop. Such as 192.168.1.113 [12.34.56.78]) in the example below: Received: from mail.origin.com (mail.origin.com [65.254.242.180]) by mail.destination.com (Postfix) with ESMTPS id 31A1B66 for u...@destination.com; Thu, 4 Dec 2014 21:00:36 +0100 (CET) Received: from [192.168.1.113] (unknown [12.34.56.78]) by mail.origin.com (Postfix) with ESMTPSA id 08AE908 for u...@destination.com; Thu, 4 Dec 2014 21:00:36 +0100 (CET) Is it possible to disable this, or would that constitute breaking standards ? Is there any use in exposing my laptop IP address? PS: I understand that in the above example, 192.168.1.113 is a non-routable IP. But it could be any IP, depending on the client. thanks, Martin A few weeks back I was also surprised to see that the client IP was being sent out in the headers. Two options that I found in my research: #1) Enabling the smtpd_sasl_authenticated_header option and using header_checks to remove that header (which if I am not mistaken checks all email). http://moblog.wiredwings.com/archives/20100501/remove-ips-from-outgoing-mail-postfix-smtp.html #2) Creating a new service in master.cf that you hook up to your submission (or otherwise authenticated) service and use header checks to search/replace against your client info as shown here: https://major.io/2013/04/14/remove-sensitive-information-from-email-headers-with-postfix/#comment-63131 That approach appears to be cleaner/more efficient as it should only touch mail sent by authenticated users and not all email. I went with option #2 about a month ago and so far so good.
Re: email header contains IP address of sending client
Am 05.12.2014 um 00:02 schrieb deoren: A few weeks back I was also surprised to see that the client IP was being sent out in the headers. Two options that I found in my research: #1) Enabling the smtpd_sasl_authenticated_header option and using header_checks to remove that header (which if I am not mistaken checks all email) that's why you should use smtp_header_checks to *not* apply such filters on incoming mail - the only relevent (if at all) is if they leave your network to the outside
No mail from yahoo or ymail
My new server does not seem to be allowing yahoo or ymail to deliver mail. I do not see anything in maillog, not supprisingly. My son reports he got a 'time out' bounce. I just set up a yahoo.com account for testing and a hour now and no email to me and no bounce message on my yahoo account. Any tricks with yahoo when you have oppurtunistic TLS and self-signed cert (I really hope neither of these are the issue).
Re: No mail from yahoo or ymail
On 12/04/2014 06:47 PM, Robert Moskowitz wrote: My new server does not seem to be allowing yahoo or ymail to deliver mail. I do not see anything in maillog, not supprisingly. My son reports he got a 'time out' bounce. I just set up a yahoo.com account for testing and a hour now and no email to me and no bounce message on my yahoo account. Any tricks with yahoo when you have oppurtunistic TLS and self-signed cert (I really hope neither of these are the issue). Oh, I had no problem sending mail to this test yahoo account. The reply to that test message has not been delivered either.
Re: No mail from yahoo or ymail
Robert Moskowitz: My new server does not seem to be allowing yahoo or ymail to deliver mail. I do not see anything in maillog, not supprisingly. My son reports he Postfix logs all connection attempts, so they are not coming through some firewall, or they aren't getting your DNS information. Wietse
Re: No mail from yahoo or ymail
On 12/04/2014 07:02 PM, Wietse Venema wrote: Robert Moskowitz: My new server does not seem to be allowing yahoo or ymail to deliver mail. I do not see anything in maillog, not supprisingly. My son reports he Postfix logs all connection attempts, so they are not coming through some firewall, or they aren't getting your DNS information. It worked before the new server, so not a firewall item, as nothing changed there. As far as DNS, I changed server name in MX record. I would hope they are getting z9m9z.htt-consult.com now rather than klovia.htt-consult.com. But there is also the spf record I added for gmail: htt-consult.com.INTXTv=spf1 mx ~all And I do get emails from gmail, and can send them to gmail.
Re: email header contains IP address of sending client
On 12/4/2014 5:18 PM, li...@rhsoft.net wrote: Am 05.12.2014 um 00:02 schrieb deoren: A few weeks back I was also surprised to see that the client IP was being sent out in the headers. Two options that I found in my research: #1) Enabling the smtpd_sasl_authenticated_header option and using header_checks to remove that header (which if I am not mistaken checks all email) that's why you should use smtp_header_checks to *not* apply such filters on incoming mail - the only relevent (if at all) is if they leave your network to the outside Thank you for the feedback. I'll read up on that option.
Re: No mail from yahoo or ymail
Robert Moskowitz: On 12/04/2014 07:02 PM, Wietse Venema wrote: Robert Moskowitz: My new server does not seem to be allowing yahoo or ymail to deliver mail. I do not see anything in maillog, not supprisingly. My son reports he Postfix logs all connection attempts, so they are not coming through some firewall, or they aren't getting your DNS information. It worked before the new server, so not a firewall item, as nothing changed there. As far as DNS, I changed server name in MX record. I would hope they are getting z9m9z.htt-consult.com now rather than klovia.htt-consult.com. But there is also the spf record I added for gmail: htt-consult.com.INTXTv=spf1 mx ~all And I do get emails from gmail, and can send them to gmail. Speaking from experience, a bad netmask on a server can have surprising effects. So can a bad netmask on a router. It totally screws up routing, and one has no idea what is going until one runs a sniffer. Wietse
Re: No mail from yahoo or ymail
On 12/04/2014 07:46 PM, Wietse Venema wrote: Robert Moskowitz: On 12/04/2014 07:02 PM, Wietse Venema wrote: Robert Moskowitz: My new server does not seem to be allowing yahoo or ymail to deliver mail. I do not see anything in maillog, not supprisingly. My son reports he Postfix logs all connection attempts, so they are not coming through some firewall, or they aren't getting your DNS information. It worked before the new server, so not a firewall item, as nothing changed there. As far as DNS, I changed server name in MX record. I would hope they are getting z9m9z.htt-consult.com now rather than klovia.htt-consult.com. But there is also the spf record I added for gmail: htt-consult.com.INTXTv=spf1 mx ~all And I do get emails from gmail, and can send them to gmail. Speaking from experience, a bad netmask on a server can have surprising effects. So can a bad netmask on a router. It totally screws up routing, and one has no idea what is going until one runs a sniffer. You said something here that triggered a thought The new server is on a different internal net than the old, thus different firewall rules. I checked over all the addressing and everything there is right, but... DCC (udp port 6277) was enabled for the old mailserver, but not the new! Could that be the problem? Well I enabled DCC and we will see as I just sent a new message from yahoo. If this does not work, I will move the new server to the old address. Really intended to do that after I turned down the old server...
