Re: virtual domains and aliases
On Tue, Nov 19, 2013 at 05:33:30PM -0500, Wietse Venema wrote:
> --8<-snip-here--8<--
> #!/bin/sh
>
> case $# in
> 0) echo usage: $0 example.com ... 1>&2; exit 1;;
> esac
>
> VIRTUAL_MAP=/etc/postfix/virtual
> VIRTUAL_DOMAINS=/etc/postfix/virtual_domains
>
> for domainname
> do
> echo postmaster@domainname root
> echo abuse@domainname root
> done >> $VIRTUAL_MAP
> postmap $VIRTUAL_MAP
>
> echo domainname >>$VIRTUAL_DOMAINS
> postmap $VIRTUAL_DOMAINS
> --8<-snip-here--8<--
Replacing domainname with "${domainname}" as required:
--8<-snip-here--8<--
#!/bin/sh
case $# in
0) echo usage: $0 example.com ... 1>&2; exit 1;;
esac
VIRTUAL_MAP=/etc/postfix/virtual
VIRTUAL_DOMAINS=/etc/postfix/virtual_domains
for domainname
do
echo "postmaster@${domainname}" root
echo "abuse@${domainname}" root
done >> $VIRTUAL_MAP
postmap $VIRTUAL_MAP
echo "${domainname} >>$VIRTUAL_DOMAINS
postmap $VIRTUAL_DOMAINS
--8<-snip-here--8<--
Run this once for each new domain. A more sophisticated approach
is to use a Makefile, with a list of domains in a separate file,
and the virtual table constructed from this and other files that
contain ad-hoc mappings.
--
Viktor.
Re: virtual domains and aliases
Pol Hallen: > > Instead, use a script that generates explicit postmas...@example.com > > entries etc. when you host a new domain. > > thanks for reply. Is there an example of that script? Need I create a > virtual domain or only something that redirect (i.e. > postmas...@example.org) to virtual domain? This example assumes: virtual_alias_maps = hash:/etc/postfix/virtual virtual_alias_domains = hash:/etc/postfix/virtual_domains Wietse --8<-snip-here--8<-- #!/bin/sh case $# in 0) echo usage: $0 example.com ... 1>&2; exit 1;; esac VIRTUAL_MAP=/etc/postfix/virtual VIRTUAL_DOMAINS=/etc/postfix/virtual_domains for domainname do echo postmaster@domainname root echo abuse@domainname root done >> $VIRTUAL_MAP postmap $VIRTUAL_MAP echo domainname >>$VIRTUAL_DOMAINS postmap $VIRTUAL_DOMAINS --8<-snip-here--8<--
Re: virtual domains and aliases
> Instead, use a script that generates explicit postmas...@example.com > entries etc. when you host a new domain. thanks for reply. Is there an example of that script? Need I create a virtual domain or only something that redirect (i.e. postmas...@example.org) to virtual domain? Thanks! Pol
Re: virtual domains and aliases
Pol Hallen: > Hi all :-) I've several virtual domains and I looking for how create the > aliases for each domains (aliases like postmaster, root, etc.) > > I found this > http://serverfault.com/questions/171616/postfix-how-to-make-aliases-work-for-virtual-domains > > that says something like this: "putting postmaster, root, etc" to > /etc/aliases: > > /^(postmaster|root|MAILER-DAEMON|abuse)@/ postmaster > /^(bin|daemon|named|nobody|uucp|www|ftp-bugs|postfix|manager|dumper|operator|decode)@/ > root That is lame: it redirects mail in other people's domains, too. > or use this: > > /^postmaster@/ postmaster > /^root@/ postmaster > /^MAILER-DAEMON@/ postmaster > > is this correct way to do this? Same problem. Instead, use a script that generates explicit postmas...@example.com entries etc. when you host a new domain. Wietse
virtual domains and aliases
Hi all :-) I've several virtual domains and I looking for how create the aliases for each domains (aliases like postmaster, root, etc.) I found this http://serverfault.com/questions/171616/postfix-how-to-make-aliases-work-for-virtual-domains that says something like this: "putting postmaster, root, etc" to /etc/aliases: /^(postmaster|root|MAILER-DAEMON|abuse)@/ postmaster /^(bin|daemon|named|nobody|uucp|www|ftp-bugs|postfix|manager|dumper|operator|decode)@/ root or use this: /^postmaster@/ postmaster /^root@/ postmaster /^MAILER-DAEMON@/ postmaster is this correct way to do this? Thanks for help! Pol
Re: Client host name resolution
>> 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"? > > No, the A record for whatever name that the PTR returned, as with the > examples above. Sorry, that's what I meant by "the domain" -- rather, the host name that the PTR lookup gives you. >> In my case, my PTR and A records look good, and online tools (mxtoolbox, > etc) seem to verify this. The "dig" command comes back looking good > as well. Yet, I keep getting "connect from unknown" (from my server, > but others, like email coming from gmail work correctly). I will have to > assume > that there is some kind of glitch in the DNS lookups Postfix is doing for my > domain/host. > > "connect from unknown" in YOUR logs has nothing to do with YOUR DNS > entries. It has to do with the DNS entries for the remote system that's > connecting to yours. Again, my language mistakes. I am testing using two separate machines. The *client* that is connecting has correct PTR and matching A record for the host name that comes back in the PTR (tests run on the server side, using "dig" or "host"), but... Ahh-ha. The host/domain *IS* recognized as expected. My issue was that when connecting to a port used for reinjecting externally filtered mail, I get "connect from unknown" - presumably because the listener is not doing DNS lookups. -o smtpd_peername_lookup=no Thanks for the pointers, very much appreciate your time
Re: Client host name resolution
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 another. However, even if the PTR lookup succeeds, the name that returns must have a matching A record. Here's an example with my own server: $ host 209.91.179.62 62.179.91.209.in-addr.arpa domain name pointer deepnet.cx. $ host deepnet.cx. deepnet.cx has address 209.91.179.62 Or from one of the outbound mail servers here at ViaNet: $ host 209.91.128.18 18.128.91.209.in-addr.arpa domain name pointer smtp1.vianet.ca. $ host smtp1.vianet.ca. smtp1.vianet.ca has address 209.91.128.18 If that second lookup returned a different IP (or a lookup failure), you get "connect from unknown". > 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"? No, the A record for whatever name that the PTR returned, as with the examples above. In the case of my personal domain deepnet.cx, everything is on one box, and I decided to just keep it simple and use the root domain in the PTR. In the case of ViaNet's systems, we have separate inbound and outbound mail clusters, and the A record for vianet.ca points to our web server, not to any of the mail systems. But all of our servers have DNS entries that form a closed loop from IP to hostname to IP. > In my case, my PTR and A records look good, and online tools (mxtoolbox, etc) > seem to verify this. The "dig" command comes back looking good as well. Yet, > I keep getting "connect from unknown" (from my server, but others, like email > coming from gmail work correctly). I will have to assume that there is some > kind of glitch in the DNS lookups Postfix is doing for my domain/host. "connect from unknown" in YOUR logs has nothing to do with YOUR DNS entries. It has to do with the DNS entries for the remote system that's connecting to yours. -kgd
Re: TLS timeout
On Nov 19, 2013, at 5:50, bitozoid wrote: > > I'm getting a TLS timeout (4.4.2) when connecting to the smarthost > (port 465). Port 465 is a legacy port and was only ever used by Outlook, as I recall. It is generally not supported by other MUAs, and I seriously doubt any MUA that is using it will support much of anything beyond the default Outlook methods for securing port 465. For example, it wouldn't support STARTTLS still is should be initiating an SSL connection from the start. Ther is no reason to use ports 465 unless you are supporting Windows95 users using Outlook (which can't use port 587, or at least not easily). Port 465 was actually reassigned for something to do with SMS and the use of it for email was deprecated 15-20 years ago.
Re: TLS timeout
On 11/19/2013 7:50 AM, bitozoid wrote: I'm getting a TLS timeout (4.4.2) when connecting to the smarthost (port 465). If I try with no TLS (port 25) it connects and sends emails. I can successfully connect with 'openssl s_client ...' and this way it says there is a 300 seconds timeout (same as in the log below). The smtp client process does not have support for the deprecated smtps protocol (465) you are trying to use. See if your smarthost supports TLS over submission (port 587) or use an stunnel as documented here: http://www.postfix.org/TLS_README.html#client_smtps Brian
TLS timeout
I'm getting a TLS timeout (4.4.2) when connecting to the smarthost (port 465). If I try with no TLS (port 25) it connects and sends emails. I can successfully connect with 'openssl s_client ...' and this way it says there is a 300 seconds timeout (same as in the log below). My postconf -n: http://pastebin.com/xjC0T7q4 I have tried adding '-v' to smtp and tlsmgr in master.cf, getting more log content but no clue. Any hint? Nov 19 12:25:21 myhost postfix/postfix-script[16192]: starting the Postfix mail system Nov 19 12:25:21 myhost postfix/master[16193]: daemon started -- version 2.6.6, configuration /etc/postfix Nov 19 12:25:43 myhost postfix/pickup[16196]: 8711E100042: uid=0 from= Nov 19 12:25:43 myhost postfix/cleanup[16205]: 8711E100042: message-id=<20131119122543.8711e100...@myhost.myrelay.net> Nov 19 12:25:43 myhost postfix/qmgr[16197]: 8711E100042: from=, size=1938, nrcpt=1 (queue active) Nov 19 12:25:43 myhost postfix/smtp[16209]: initializing the client-side TLS engine Nov 19 12:30:43 myhost postfix/smtp[16209]: 8711E100042: lost connection with mail.myrelay.org[10.141.139.18] while receiving the initial server greeting
Re: Client host name resolution
>>> 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 well. >> >> Sometimes there will be a PTR record, but no matching A record. >> >> Also keep in mind that if there is a temporary glitch in DNS resolution, >> either the PTR or A lookup might fail when the message first passes >> through, but looks fine later on when you check by hand. > > Thanks. So my understanding is correct that Postfix gets the hostnames you > see > in the logs from PTR records? And that "connect from unknown[1.2.3.4]" > is caused by a missing PTR (or DNS issue)? > > 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"? > > That would all make sense. > > In my case, my PTR and A records look good, and online tools (mxtoolbox, etc) > seem to verify this. The "dig" command comes back looking good as > well. Yet, I keep getting "connect from unknown" (from my server, but > others, like email coming from gmail work correctly). I will have to assume > that there is some kind of glitch in the DNS lookups Postfix is doing for my > domain/host. Oh, and no, the smptd server is not running chroot
Re: Client host name resolution
> 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 the log and Received: header, the PTR > name must then resolve back to that same IP as well. > > Sometimes there will be a PTR record, but no matching A record. > > Also keep in mind that if there is a temporary glitch in DNS resolution, > either the PTR or A lookup might fail when the message first passes > through, but looks fine later on when you check by hand. Thanks. So my understanding is correct that Postfix gets the hostnames you see in the logs from PTR records? And that "connect from unknown[1.2.3.4]" is caused by a missing PTR (or DNS issue)? 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"? That would all make sense. In my case, my PTR and A records look good, and online tools (mxtoolbox, etc) seem to verify this. The "dig" command comes back looking good as well. Yet, I keep getting "connect from unknown" (from my server, but others, like email coming from gmail work correctly). I will have to assume that there is some kind of glitch in the DNS lookups Postfix is doing for my domain/host. Thanks again.
