Re: user authentication and password format

[Robert Moskowitz]

On 2/12/19 11:37 AM, Patrick Ben Koetter wrote:

* Robert Moskowitz :

For my new server, I plan on using either SHA256 or 512 and trying to see
what impact NOT using MD5 has on the postfix configuration. I am assuming
that this only impacts the sasl authentication and I am seeing:

# postconf -n|grep sasl
broken_sasl_auth_clients = yes
smtpd_recipient_restrictions = permit_sasl_authenticated, permit_mynetworks,
rej
ect_unauth_destination, reject_non_fqdn_sender, reject_non_fqdn_recipient,
rejec
t_unknown_recipient_domain
smtpd_sasl_auth_enable = yes
smtpd_sasl_local_domain = $mydomain
smtpd_sasl_path = private/auth
smtpd_sasl_type = dovecot

That postfix let's dovecot do the authentication lifting and so only dovecot
needs to know the password format and that is in dovecot-sql.conf,

Is that the extent of it, or is there somewhere else I need to specify the
password format.

It's all left to dovecot. From Postfix' point of view dovecot acts as password
verification service. Postfix hands over the indentity data, dovecot
authenticates the identity and returns the result and Postfix authorizes the
identity to e.g. relay mails.


Thanks.  That is at least one place not needing changes.

Just postfixadmin, dovecot, and roundcubemail.  Manageable.

user authentication and password format

[Robert Moskowitz]

For my new server, I plan on using either SHA256 or 512 and trying to 
see what impact NOT using MD5 has on the postfix configuration. I am 
assuming that this only impacts the sasl authentication and I am seeing:


# postconf -n|grep sasl
broken_sasl_auth_clients = yes
smtpd_recipient_restrictions = permit_sasl_authenticated, 
permit_mynetworks, rej
ect_unauth_destination, reject_non_fqdn_sender, 
reject_non_fqdn_recipient, rejec

t_unknown_recipient_domain
smtpd_sasl_auth_enable = yes
smtpd_sasl_local_domain = $mydomain
smtpd_sasl_path = private/auth
smtpd_sasl_type = dovecot

That postfix let's dovecot do the authentication lifting and so only 
dovecot needs to know the password format and that is in dovecot-sql.conf,


Is that the extent of it, or is there somewhere else I need to specify 
the password format.


thanks

Re: PATCH: Problems invoking amavis from postfix

[Robert Moskowitz]

On 2/8/19 2:31 PM, Wietse Venema wrote:

Robert Moskowitz:


On 2/8/19 2:10 PM, Viktor Dukhovni wrote:

On Feb 8, 2019, at 2:07 PM, Robert Moskowitz  wrote:

Much easier to automate changes (as we had nothing like postconf -e for 
changing master.cf).  If I read the patch right, you are providing a warning of 
the double entry.  Perhaps a better patch would warn and drop all but the last 
entry?

It is not the job of master(8) to edit master.cf.  Indeed that file
might reside in read-only storage.

If you meant "use only the last one", as Wietse also notes, that's the
current behaviour.


Ah, so it is my muddled reading.

I did not think that postfix should edit master.cf. Only its internal
processes would use the last entry found.

To make this abundantly clear, adding this warning does not change program 
behavior.


I did see that, and because i assumed Viktor's typo (and I am a master 
at making typos) was a 'new' insight (for me) into postfix that there 
was something more at work here.


Got it all now.

I hope.

:)

Re: PATCH: Problems invoking amavis from postfix

[Robert Moskowitz]

On 2/8/19 2:10 PM, Viktor Dukhovni wrote:

On Feb 8, 2019, at 2:07 PM, Robert Moskowitz  wrote:

Much easier to automate changes (as we had nothing like postconf -e for 
changing master.cf).  If I read the patch right, you are providing a warning of 
the double entry.  Perhaps a better patch would warn and drop all but the last 
entry?

It is not the job of master(8) to edit master.cf.  Indeed that file
might reside in read-only storage.

If you meant "use only the last one", as Wietse also notes, that's the
current behaviour.


Ah, so it is my muddled reading.

I did not think that postfix should edit master.cf.  Only its internal 
processes would use the last entry found.

Re: PATCH: Problems invoking amavis from postfix

[Robert Moskowitz]

On 2/8/19 2:08 PM, Wietse Venema wrote:

Robert Moskowitz:


On 2/8/19 1:44 PM, Wietse Venema wrote:

Viktor Dukhovni:

pickup unix   n - n 60   1  
   pickup
pickup unix   n - n 60   1  
   pickup
  -o content_filter=

The "pickup" service is defined twice in master.c, the second
instance (last one wins) disables content filtering for mail submitted
locally via sendmail(1).

That was easy enough to fix:

When I was working on this 2 years ago, I thought it was kind of cool
that instead of editing master.cf entries to fix them, I could just
append a whole new entry with the 'right' content.

Much easier to automate changes (as we had nothing like postconf -e for
changing master.cf).? If I read the patch right, you are providing a
warning of the double entry.? Perhaps a better patch would warn and drop
all but the last entry?

Why do you think it was keeping both pickup entries?


Well, I am not sure.  From Viktor's earlier note, it seems that the last 
wins and the earlier ones are just ignored.  Maybe it is that Viktor 
said, "master.c" and I don't know what "master.c" different from 
"master.cf" that is in /etc/postfix.


I kind of assumed (and we know what that is an abbreviation for) that 
"master.c" is an internal entry in postfix built from processing 
master.cf.  Thus why keep all but the last in the internal table?

Re: PATCH: Problems invoking amavis from postfix

[Robert Moskowitz]

On 2/8/19 1:44 PM, Wietse Venema wrote:

Viktor Dukhovni:

pickup unix   n - n 60   1  
   pickup
pickup unix   n - n 60   1  
   pickup
 -o content_filter=

The "pickup" service is defined twice in master.c, the second
instance (last one wins) disables content filtering for mail submitted
locally via sendmail(1).

That was easy enough to fix:


When I was working on this 2 years ago, I thought it was kind of cool 
that instead of editing master.cf entries to fix them, I could just 
append a whole new entry with the 'right' content.


Much easier to automate changes (as we had nothing like postconf -e for 
changing master.cf).  If I read the patch right, you are providing a 
warning of the double entry.  Perhaps a better patch would warn and drop 
all but the last entry?





Feb  8 13:42:53 spike postfix/master[53597]: warning: duplicate master.cf entry for 
service "pickup" (public/pickup)-- using the last entry

--- ./src/master/master_conf.c- 2019-02-08 13:39:50.0 -0500
+++ ./src/master/master_conf.c  2019-02-08 13:36:28.0 -0500
@@ -117,6 +117,14 @@
}
  
  	/*

+* Warn about duplicate entry.
+*/
+   else if ((serv->flags & MASTER_FLAG_MARK) == 0) {
+   msg_warn("duplicate master.cf entry for service \"%s\" (%s)"
+"-- using the last entry", serv->ext_name, serv->name);
+   }
+
+   /*
 * Update an existing service entry. Make the current generation of
 * child processes commit suicide whenever it is convenient. The next
 * generation of child processes will run with the new configuration

Re: Problems invoking amavis from postfix

[Robert Moskowitz]

On 2/8/19 1:42 PM, Viktor Dukhovni wrote:

On Feb 8, 2019, at 1:26 PM, Robert Moskowitz  wrote:

Like I said, I am obviously missing something simple I am not doing.

I pulled out that 2nd pickup entry (and I know where I picked up doing this, 
sigh):

Be careful to not introduce loops.  That override to skip content filters
with pickup(8) is required if you even decide to use "simple content filters"
as described in FILTER_README.  If all your filters are SMTP or LMTP, and
you want to filter local submission, then it is safe to remove the overide.

Digging back into my notes from 2 years ago, avoiding the loop was why I 
added the content_filter override AFTER I had tested the antivirus 
scanning.  Grumble, grumble.


I am going to leave it out for now.  I will revisit this when I start 
working on using MILTER and adding DKIM and such.  For now, I have to 
get this system upgrade completed.  Getting close.

Re: Problems invoking amavis from postfix

[Robert Moskowitz]

On 2/8/19 12:42 PM, Dominic Raferd wrote:

On Fri, 8 Feb 2019 at 17:33, Viktor Dukhovni  wrote:


#postconf -Mxf

pickup unix   n - n 60   1  
   pickup
pickup unix   n - n 60   1  
   pickup
 -o content_filter=

The "pickup" service is defined twice in master.c, the second
instance (last one wins) disables content filtering for mail submitted
locally via sendmail(1).

I have to say - great catch ;-)


Like I said, I am obviously missing something simple I am not doing.

I pulled out that 2nd pickup entry (and I know where I picked up doing 
this, sigh):


Feb  8 13:22:30 klovia postfix/master[14289]: reload -- version 2.10.1, 
configuration /etc/postfix

Feb  8 13:22:49 klovia postfix/pickup[14743]: E01D25B15: uid=0 from=
Feb  8 13:22:49 klovia postfix/cleanup[14751]: E01D25B15: 
message-id=<20190208182249.e01d25...@klovia.htt-consult.com>
Feb  8 13:22:50 klovia postfix/qmgr[14744]: E01D25B15: 
from=, size=430, nrcpt=1 (queue active)
Feb  8 13:22:50 klovia amavis[13505]: (13505-02) LMTP [127.0.0.1]:10024 
/var/spool/amavisd/tmp/amavis-20190208T132250-13505-c4dwb85j: 
 ->  SIZE=430 
Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost 
(klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP 
for ; Fri,  8 Feb 2019 13:22:50 -0500 (EST)
Feb  8 13:22:50 klovia amavis[13505]: (13505-02) Checking: ry67P_Ijljpy 
[127.0.0.1]  -> 
Feb  8 13:22:50 klovia clamd[6346]: 
/var/spool/amavisd/tmp/amavis-20190208T132250-13505-c4dwb85j/parts/p002: 
Eicar-Test-Signature FOUND
Feb  8 13:22:50 klovia clamd[6346]: 
/var/spool/amavisd/tmp/amavis-20190208T132250-13505-c4dwb85j/parts/p001: 
Eicar-Test-Signature FOUND
Feb  8 13:22:50 klovia amavis[13505]: (13505-02) Blocked INFECTED 
(Eicar-Test-Signature) {DiscardedInbound,Quarantined}, [127.0.0.1] 
 -> , Message-ID: 
<20190208182249.e01d25...@klovia.htt-consult.com>, mail_id: 
ry67P_Ijljpy, Hits: -, size: 430, 383 ms
Feb  8 13:22:50 klovia postfix/lmtp[14755]: E01D25B15: 
to=, relay=127.0.0.1[127.0.0.1]:10024, 
delay=3, delays=2.5/0.04/0.01/0.39, dsn=2.7.0, status=sent (250 2.7.0 
Ok, discarded, id=13505-02 - INFECTED: Eicar-Test-Signature)

Feb  8 13:22:50 klovia postfix/qmgr[14744]: E01D25B15: removed


thank you, thank you, thank you...

Re: Problems invoking amavis from postfix

[Robert Moskowitz]

On 2/8/19 12:32 PM, Wietse Venema wrote:

Robert Moskowitz:

Never overlook the impossible: what is logged when you execute
"postfix reload"?  Does that configuration directory match the
location of the main.cf and master.cf files that you report here?

I suspect it is something 'obvious', but I don't think it is this:

One more:

ps ax|grep master


13500 ?    Ss 0:11 /usr/sbin/amavisd (master)
14289 ?    Ss 0:01 /usr/libexec/postfix/master -w
14729 ttySAC2  S+ 0:00 grep --color=auto master

Re: Problems invoking amavis from postfix

[Robert Moskowitz]

On 2/8/19 12:05 PM, Wietse Venema wrote:

Robert Moskowitz:

Wietse, thanks for responding.

On 2/8/19 11:31 AM, Wietse Venema wrote:

Robert Moskowitz:

Something is wrong, but I have yet to find it.
Any and all help greatly appreciated.

If you could summarize in one line what is wrong.

It does not seem that amavis-new is being called by postfix.  The test
Eicar message goes right through into INBOX.

Never overlook the impossible: what is logged when you execute
"postfix reload"?  Does that configuration directory match the
location of the main.cf and master.cf files that you report here?


Here is some more information (asked in a private mail):

# postconf smtpd_milters content_filter smtpd_proxy_filter

smtpd_milters =
content_filter = amavisfeed:[127.0.0.1]:10024
smtpd_proxy_filter =

#postconf -Mxf

pickup unix  n   -   n   60  1   pickup
cleanup    unix  n   -   n   -   0   cleanup
qmgr   unix  n   -   n   300 1   qmgr
tlsmgr unix  -   -   n   1000?   1   tlsmgr
rewrite    unix  -   -   n   -   - trivial-rewrite
bounce unix  -   -   n   -   0   bounce
defer  unix  -   -   n   -   0   bounce
trace  unix  -   -   n   -   0   bounce
verify unix  -   -   n   -   1   verify
flush  unix  n   -   n   1000?   0   flush
proxymap   unix  -   -   n   -   -   proxymap
proxywrite unix  -   -   n   -   1   proxymap
smtp   unix  -   -   n   -   -   smtp
relay  unix  -   -   n   -   -   smtp
showq  unix  n   -   n   -   -   showq
error  unix  -   -   n   -   -   error
retry  unix  -   -   n   -   -   error
discard    unix  -   -   n   -   -   discard
local  unix  -   n   n   -   -   local
virtual    unix  -   n   n   -   -   virtual
lmtp   unix  -   -   n   -   -   lmtp
anvil  unix  -   -   n   -   1   anvil
scache unix  -   -   n   -   1   scache
Smtpd  pass  -   -   n   -   -   smtpd -v
submission inet  n   -   n   -   -   smtpd -v
    -o syslog_name=postfix/submission -o smtpd_tls_wrappermode=no
    -o smtpd_tls_security_level = encrypt -o smtpd_sasl_auth_enable=yes -o
smtpd_relay_restrictions=permit_mynetworks,permit_sasl_authenticated,defer_unauth_destination 


    -o milter_macro_daemon_name=ORIGINATING
pickup unix  n   -   n   60  1   pickup
    -o content_filter=
relay  unix  -   -   n   -   -   smtp
    -o fallback_relay=
maildrop   unix  -   n   n   -   -   pipe
    flags=DRhu user=vmail argv=/usr/local/bin/maildrop -d ${recipient}
uucp   unix  -   n   n   -   -   pipe
    flags=Fqhu user=uucp argv=uux -r -n -z -a$sender - $nexthop!rmail
    ($recipient)
ifmail unix  -   n   n   -   -   pipe
    flags=F user=ftn argv=/usr/lib/ifmail/ifmail -r $nexthop ($recipient)
bsmtp  unix  -   n   n   -   -   pipe
    flags=Fq. user=bsmtp argv=/usr/local/sbin/bsmtp -f $sender $nexthop
    $recipient
amavisfeed unix  -   -   y   -   2   lmtp
    -o lmtp_data_done_timeout=1200 -o lmtp_send_xforward_command=yes
    -o disable_dns_lookups=yes -o max_use=20
127.0.0.1:10025 inet n   -   n   -   -   smtpd
    -o content_filter= -o smtpd_delay_reject=no
    -o smtpd_client_restrictions=permit_mynetworks,reject
    -o smtpd_helo_restrictions= -o smtpd_sender_restrictions=
    -o smtpd_recipient_restrictions=permit_mynetworks,reject
    -o smtpd_data_restrictions=reject_unauth_pipelining
    -o smtpd_end_of_data_restrictions= -o smtpd_restriction_classes=
    -o mynetworks=127.0.0.0/8 -o smtpd_error_sleep_time=0
    -o smtpd_soft_error_limit=1001 -o smtpd_hard_error_limit=1000
    -o smtpd_client_connection_count_limit=0
    -o smtpd_client_connection_rate_limit=0
    -o 
receive_override_options=no_header_body_checks,no_unknown_recipient_checks,no_milters,no_address_mappings
    -o local_header_rewrite_clients= -o smtpd_milters= -o 
local_recipient_maps=

    -o relay_recipient_maps=
dovecot    unix  -   n   n   -   -   pipe
    flags=DRhu user=vmail:mail argv=/usr/libexec/dovecot/deliver -d
    ${recipient}
vacation   unix  -   n   n   -   -   pipe
    flags=Rq user=vacation argv=/var/spool/vacation/vacation.pl -f 
${sender} --

    ${recipient}

Re: Problems invoking amavis from postfix

[Robert Moskowitz]

On 2/8/19 12:05 PM, Wietse Venema wrote:

Robert Moskowitz:

Wietse, thanks for responding.

On 2/8/19 11:31 AM, Wietse Venema wrote:

Robert Moskowitz:

Something is wrong, but I have yet to find it.
Any and all help greatly appreciated.

If you could summarize in one line what is wrong.

It does not seem that amavis-new is being called by postfix.  The test
Eicar message goes right through into INBOX.

Never overlook the impossible: what is logged when you execute
"postfix reload"?  Does that configuration directory match the
location of the main.cf and master.cf files that you report here?


I suspect it is something 'obvious', but I don't think it is this:

# postfix reload
postfix/postfix-script: refreshing the Postfix mail system
# tail /var/log/maillog -n10
Feb  8 11:52:22 klovia postfix/pickup[14557]: D519D5B15: uid=0 from=
Feb  8 11:52:22 klovia postfix/cleanup[14563]: D519D5B15: 
message-id=<20190208165222.d519d5...@klovia.htt-consult.com>
Feb  8 11:52:22 klovia postfix/qmgr[14558]: D519D5B15: 
from=, size=430, nrcpt=1 (queue active)
Feb  8 11:52:23 klovia dovecot: lda(r...@test.htt-consult.com): sieve: 
msgid=<20190208165222.d519d5...@klovia.htt-consult.com>: stored mail 
into mailbox 'INBOX'
Feb  8 11:52:23 klovia postfix/pipe[14570]: D519D5B15: 
to=, relay=dovecot, delay=0.72, 
delays=0.22/0.05/0/0.45, dsn=2.0.0, status=sent (delivered via dovecot 
service)

Feb  8 11:52:23 klovia postfix/qmgr[14558]: D519D5B15: removed
Feb  8 12:00:53 klovia clamd[6346]: SelfCheck: Database status OK.
Feb  8 12:10:53 klovia clamd[6346]: SelfCheck: Database status OK.
Feb  8 12:18:32 klovia postfix/postfix-script[14641]: refreshing the 
Postfix mail system
Feb  8 12:18:32 klovia postfix/master[14289]: reload -- version 2.10.1, 
configuration /etc/postfix


And /etc/postfix is where I have my edited mail.cf and master.cf.

Re: Problems invoking amavis from postfix

[Robert Moskowitz]

On 2/8/19 11:36 AM, Dominic Raferd wrote:

On Fri, 8 Feb 2019 at 16:18, Robert Moskowitz  wrote:

I have dug some more and not found anything to help.  I went through 
http://www.postfix.org/docs.html where 2 of the amavis howtos are no longer 
available.  I have replicated the main.cf and master.cf as shown in 
http://www.shisaa.jp/postset/mailserver-1.html and still no apparent running of 
amavis on the test messages.

I have tried to get debugging working on postfix.  After reading 
http://www.postfix.org/DEBUG_README.html, I have tried appending -v to the 
smtpd lines in master.cf and not seen any more detail.  All I am seeing is:

Feb  8 11:11:45 klovia postfix/pickup[14472]: 3DD4059DA: uid=0 from=
Feb  8 11:11:45 klovia postfix/cleanup[14478]: 3DD4059DA: 
message-id=<20190208161145.3dd405...@klovia.htt-consult.com>
Feb  8 11:11:45 klovia postfix/qmgr[14473]: 3DD4059DA: 
from=, size=430, nrcpt=1 (queue active)
Feb  8 11:11:45 klovia dovecot: lda(r...@test.htt-consult.com): sieve: 
msgid=<20190208161145.3dd405...@klovia.htt-consult.com>: stored mail into 
mailbox 'INBOX'
Feb  8 11:11:45 klovia postfix/pipe[14484]: 3DD4059DA: 
to=, relay=dovecot, delay=1.1, 
delays=0.8/0.05/0/0.22, dsn=2.0.0, status=sent (delivered via dovecot service)
Feb  8 11:11:45 klovia postfix/qmgr[14473]: 3DD4059DA: removed

Something is wrong, but I have yet to find it.

Any and all help greatly appreciated.

Try sending to amavis via smtp, not lmtp, this is the way I have it
set up in master.cf (extract only):

...
amavis unix - - y - 2 smtp
-o smtp_data_done_timeout=1200
-o smtp_send_xforward_command=yes
...


FWIW, my current, 4 year old system works with lmtp and all the docs I 
have read say to use lmtp, but I will give this a try.




and check for the setting of inet_socket_port in amavis, which needs
to be 10024 (set as default in debian, but not in original
amavisd-new):
grep -r \$inet_socket_port /etc/amavis



# grep -r \$inet_socket_port /etc/amavisd
/etc/amavisd/amavisd.conf:   # option(s) -p overrides 
$inet_socket_port and $unix_socketname
/etc/amavisd/amavisd.conf:$inet_socket_port = 10024;   # listen on this 
local TCP port(s)
/etc/amavisd/amavisd.conf:# $inet_socket_port = [10024,10026];  # listen 
on multiple TCP ports


So that is right.  And I have tested this with 'telnet localhost 10024'.



You will need to restart amavis after any configuration changes, and
maybe reload postfix too (it's easy enough).

Re: Problems invoking amavis from postfix

[Robert Moskowitz]

Wietse, thanks for responding.

On 2/8/19 11:31 AM, Wietse Venema wrote:

Robert Moskowitz:

Something is wrong, but I have yet to find it.
Any and all help greatly appreciated.

If you could summarize in one line what is wrong.


It does not seem that amavis-new is being called by postfix.  The test 
Eicar message goes right through into INBOX.




- You configured amavis via 'content_filter' but it is not being used?
   In that case, what is the output from:

   postconf -n content_filter


content_filter = amavisfeed:[127.0.0.1]:10024


   postconf -P "*/*/content_filter"

   "postconf -P" requires Postfix 2.11 or later (released five years
   ago, it is no longer supported).


And CentOS7 is still on 2.10.1


- Something else? amavis via Milter API, but it is not being used?


Besides the content_filter in main.cf, I have the 'typical' lines in 
master.cf:


amavisfeed unix    -    -    y    -    2    lmtp
    -o lmtp_data_done_timeout=1200
    -o lmtp_send_xforward_command=yes
    -o disable_dns_lookups=yes
    -o max_use=20
127.0.0.1:10025 inet n    -    n    -    -    smtpd
    -o content_filter=
    -o smtpd_delay_reject=no
    -o smtpd_client_restrictions=permit_mynetworks,reject
    -o smtpd_helo_restrictions=
    -o smtpd_sender_restrictions=
    -o smtpd_recipient_restrictions=permit_mynetworks,reject
    -o smtpd_data_restrictions=reject_unauth_pipelining
    -o smtpd_end_of_data_restrictions=
    -o smtpd_restriction_classes=
    -o mynetworks=127.0.0.0/8
    -o smtpd_error_sleep_time=0
    -o smtpd_soft_error_limit=1001
    -o smtpd_hard_error_limit=1000
    -o smtpd_client_connection_count_limit=0
    -o smtpd_client_connection_rate_limit=0
    -o 
receive_override_options=no_header_body_checks,no_unknown_recipient_checks,no_milters,no_address_mappings

    -o local_header_rewrite_clients=
    -o smtpd_milters=
    -o local_recipient_maps=
    -o relay_recipient_maps=

I suspect there is something else I have left out.



Wietse

Re: Problems invoking amavis from postfix

[Robert Moskowitz]

I have dug some more and not found anything to help.  I went through 
http://www.postfix.org/docs.html where 2 of the amavis howtos are no 
longer available.  I have replicated the main.cf and master.cf as shown 
in http://www.shisaa.jp/postset/mailserver-1.html and still no apparent 
running of amavis on the test messages.


I have tried to get debugging working on postfix.  After reading 
http://www.postfix.org/DEBUG_README.html, I have tried appending -v to 
the smtpd lines in master.cf and not seen any more detail.  All I am 
seeing is:


Feb  8 11:11:45 klovia postfix/pickup[14472]: 3DD4059DA: uid=0 from=
Feb  8 11:11:45 klovia postfix/cleanup[14478]: 3DD4059DA: 
message-id=<20190208161145.3dd405...@klovia.htt-consult.com>
Feb  8 11:11:45 klovia postfix/qmgr[14473]: 3DD4059DA: 
from=, size=430, nrcpt=1 (queue active)
Feb  8 11:11:45 klovia dovecot: lda(r...@test.htt-consult.com): sieve: 
msgid=<20190208161145.3dd405...@klovia.htt-consult.com>: stored mail 
into mailbox 'INBOX'
Feb  8 11:11:45 klovia postfix/pipe[14484]: 3DD4059DA: 
to=, relay=dovecot, delay=1.1, 
delays=0.8/0.05/0/0.22, dsn=2.0.0, status=sent (delivered via dovecot 
service)

Feb  8 11:11:45 klovia postfix/qmgr[14473]: 3DD4059DA: removed

Something is wrong, but I have yet to find it.

Any and all help greatly appreciated.

On 2/7/19 4:16 PM, Robert Moskowitz wrote:
I am building a new system on CentOS7 that has postfix 2.10.1 and 
amavis-new 2.11.1


I am working from my notes of 2 years ago when I last did this 
successfully so either something has changed since then (quite 
likely), or I am missing something from my notes (also quite likely).


For main.cf I run:

postconf -e 'content_filter = amavis:[127.0.0.1]:10024'

Then I append to the default master.cf (working from my understanding 
that the last instruction in master.cf encountered is the one applied, 
rather than trying to edit what is there):


# 
== 
# service type private unpriv chroot wakeup maxproc command + args # 
(yes) (yes) (yes) (never) (100) # 
== 
smtpd pass - - n - - smtpd submission inet n - n - - smtpd -o 
smtpd_recipient_restrictions= pickup unix n - n 60 1 pickup -o 
content_filter= relay unix - - n - - smtp -o fallback_relay= maildrop 
unix - n n - - pipe flags=DRhu user=vmail argv=/usr/local/bin/maildrop 
-d ${recipient} uucp unix - n n - - pipe flags=Fqhu user=uucp argv=uux 
-r -n -z -a$sender - $nexthop!rmail ($recipient) ifmail unix - n n - - 
pipe flags=F user=ftn argv=/usr/lib/ifmail/ifmail -r $nexthop 
($recipient) bsmtp unix - n n - - pipe flags=Fq. user=bsmtp 
argv=/usr/local/sbin/bsmtp -f $sender $nexthop $recipient # # 
spam/virus section # amavis unix - - y - 2 lmtp -o 
lmtp_data_done_timeout=1200 -o lmtp_send_xforward_command=yes -o 
disable_dns_lookups=yes -o max_use=20 127.0.0.1:10025 inet n - n - - 
smtpd -o content_filter= -o smtpd_delay_reject=no -o 
smtpd_client_restrictions=permit_mynetworks,reject -o 
smtpd_helo_restrictions= -o smtpd_sender_restrictions= -o 
smtpd_recipient_restrictions=permit_mynetworks,reject -o 
smtpd_data_restrictions=reject_unauth_pipelining -o 
smtpd_end_of_data_restrictions= -o smtpd_restriction_classes= -o 
mynetworks=127.0.0.0/8 -o smtpd_error_sleep_time=0 -o 
smtpd_soft_error_limit=1001 -o smtpd_hard_error_limit=1000 -o 
smtpd_client_connection_count_limit=0 -o 
smtpd_client_connection_rate_limit=0 -o 
receive_override_options=no_header_body_checks,no_unknown_recipient_checks,no_milters 
-o local_header_rewrite_clients= -o smtpd_milters= -o 
local_recipient_maps= -o relay_recipient_maps= # # Dovecot LDA dovecot 
unix - n n - - pipe flags=DRhu user=vmail:mail 
argv=/usr/libexec/dovecot/deliver -d ${recipient} # # Vacation mail 
vacation unix - n n - - pipe flags=Rq user=vacation 
argv=/var/spool/vacation/vacation.pl -f ${sender} -- ${recipient}


Dovecot is working just fine, BTW.  So I run a couple of tests:

sendmail -i r...@test.htt-consult.com < sample-virus-simple.txt

Feb  7 12:52:57 klovia postfix/pickup[11341]: 9347458EC: uid=0 from=
Feb  7 12:52:57 klovia postfix/cleanup[11458]: 9347458EC: 
message-id=<20190207175257.934745...@klovia.htt-consult.com>
Feb  7 12:52:57 klovia postfix/qmgr[6089]: 9347458EC: 
from=, size=430, nrcpt=1 (queue active)
Feb  7 12:52:58 klovia dovecot: lda(r...@test.htt-consult.com): sieve: 
msgid=<20190207175257.934745...@klovia.htt-consult.com>: stored mail 
into mailbox 'INBOX'
Feb  7 12:52:58 klovia postfix/pipe[11465]: 9347458EC: 
to=, relay=dovecot, delay=4.3, 
delays=3.4/0.08/0/0.77, dsn=2.0.0, status=sent (delivered via dovecot 
service)

Feb  7 12:52:58 klovia postfix/qmgr[6089]: 9347458EC: removed


sendmail -i r...@test.htt-consult.com < sample-spam-GTUBE-junk.txt

Feb  7 12:54:08 klovia postfix/pickup[11341]: 860DE58EC: uid=0 from=
Feb  7 12:54:08 klovia postfix/cleanup[11458]: 860DE58EC

Problems invoking amavis from postfix

[Robert Moskowitz]

I am building a new system on CentOS7 that has postfix 2.10.1 and 
amavis-new 2.11.1


I am working from my notes of 2 years ago when I last did this 
successfully so either something has changed since then (quite likely), 
or I am missing something from my notes (also quite likely).


For main.cf I run:

postconf -e 'content_filter = amavis:[127.0.0.1]:10024'

Then I append to the default master.cf (working from my understanding 
that the last instruction in master.cf encountered is the one applied, 
rather than trying to edit what is there):


# 
== 
# service type private unpriv chroot wakeup maxproc command + args # 
(yes) (yes) (yes) (never) (100) # 
== 
smtpd pass - - n - - smtpd submission inet n - n - - smtpd -o 
smtpd_recipient_restrictions= pickup unix n - n 60 1 pickup -o 
content_filter= relay unix - - n - - smtp -o fallback_relay= maildrop 
unix - n n - - pipe flags=DRhu user=vmail argv=/usr/local/bin/maildrop 
-d ${recipient} uucp unix - n n - - pipe flags=Fqhu user=uucp argv=uux 
-r -n -z -a$sender - $nexthop!rmail ($recipient) ifmail unix - n n - - 
pipe flags=F user=ftn argv=/usr/lib/ifmail/ifmail -r $nexthop 
($recipient) bsmtp unix - n n - - pipe flags=Fq. user=bsmtp 
argv=/usr/local/sbin/bsmtp -f $sender $nexthop $recipient # # spam/virus 
section # amavis unix - - y - 2 lmtp -o lmtp_data_done_timeout=1200 -o 
lmtp_send_xforward_command=yes -o disable_dns_lookups=yes -o max_use=20 
127.0.0.1:10025 inet n - n - - smtpd -o content_filter= -o 
smtpd_delay_reject=no -o 
smtpd_client_restrictions=permit_mynetworks,reject -o 
smtpd_helo_restrictions= -o smtpd_sender_restrictions= -o 
smtpd_recipient_restrictions=permit_mynetworks,reject -o 
smtpd_data_restrictions=reject_unauth_pipelining -o 
smtpd_end_of_data_restrictions= -o smtpd_restriction_classes= -o 
mynetworks=127.0.0.0/8 -o smtpd_error_sleep_time=0 -o 
smtpd_soft_error_limit=1001 -o smtpd_hard_error_limit=1000 -o 
smtpd_client_connection_count_limit=0 -o 
smtpd_client_connection_rate_limit=0 -o 
receive_override_options=no_header_body_checks,no_unknown_recipient_checks,no_milters 
-o local_header_rewrite_clients= -o smtpd_milters= -o 
local_recipient_maps= -o relay_recipient_maps= # # Dovecot LDA dovecot 
unix - n n - - pipe flags=DRhu user=vmail:mail 
argv=/usr/libexec/dovecot/deliver -d ${recipient} # # Vacation mail 
vacation unix - n n - - pipe flags=Rq user=vacation 
argv=/var/spool/vacation/vacation.pl -f ${sender} -- ${recipient}



Dovecot is working just fine, BTW.  So I run a couple of tests:

sendmail -i r...@test.htt-consult.com < sample-virus-simple.txt

Feb  7 12:52:57 klovia postfix/pickup[11341]: 9347458EC: uid=0 from=
Feb  7 12:52:57 klovia postfix/cleanup[11458]: 9347458EC: 
message-id=<20190207175257.934745...@klovia.htt-consult.com>
Feb  7 12:52:57 klovia postfix/qmgr[6089]: 9347458EC: 
from=, size=430, nrcpt=1 (queue active)
Feb  7 12:52:58 klovia dovecot: lda(r...@test.htt-consult.com): sieve: 
msgid=<20190207175257.934745...@klovia.htt-consult.com>: stored mail 
into mailbox 'INBOX'
Feb  7 12:52:58 klovia postfix/pipe[11465]: 9347458EC: 
to=, relay=dovecot, delay=4.3, 
delays=3.4/0.08/0/0.77, dsn=2.0.0, status=sent (delivered via dovecot 
service)

Feb  7 12:52:58 klovia postfix/qmgr[6089]: 9347458EC: removed


sendmail -i r...@test.htt-consult.com < sample-spam-GTUBE-junk.txt

Feb  7 12:54:08 klovia postfix/pickup[11341]: 860DE58EC: uid=0 from=
Feb  7 12:54:08 klovia postfix/cleanup[11458]: 860DE58EC: 
message-id=
Feb  7 12:54:08 klovia postfix/qmgr[6089]: 860DE58EC: 
from=, size=941, nrcpt=1 (queue active)
Feb  7 12:54:09 klovia dovecot: lda(r...@test.htt-consult.com): sieve: 
msgid=: stored mail into mailbox 'INBOX'
Feb  7 12:54:09 klovia postfix/pipe[11465]: 860DE58EC: 
to=, relay=dovecot, delay=0.89, 
delays=0.37/0.02/0/0.5, dsn=2.0.0, status=sent (delivered via dovecot 
service)

Feb  7 12:54:09 klovia postfix/qmgr[6089]: 860DE58EC: removed


Both right to INBOX.  Obviously I am missing something.  I have spent 
the day reading over stuff, but I am missing what I am missing.


I hope someone here can lend a hand.  I suspect it is a 'small' 
oversight as that all it takes.


thanks


Oh, and here is the status of amavisd:

# systemctl -l status amavisd
● amavisd.service - Amavisd-new is an interface between MTA and content 
checkers.
   Loaded: loaded (/usr/lib/systemd/system/amavisd.service; enabled; 
vendor preset: disabled)

   Active: active (running) since Thu 2019-02-07 08:16:59 EST; 7h ago
 Docs: http://www.ijs.si/software/amavisd/#doc
  Process: 5715 ExecStart=/usr/sbin/amavisd -c 
/etc/amavisd/amavisd.conf (code=exited, status=0/SUCCESS)

 Main PID: 6327 (/usr/sbin/amavi)
   CGroup: /system.slice/amavisd.service
   ├─6327 /usr/sbin/amavisd (master)
   ├─6336 /usr/sbin/amavisd (virgin child)
   └─6337 /usr/sbin/amavisd (virgin 

Re: enabling xforward in ehlo

[Robert Moskowitz]

On 04/24/2017 11:54 PM, Viktor Dukhovni wrote:

On Apr 24, 2017, at 5:43 PM, Robert Moskowitz <r...@htt-consult.com> wrote:


http://www.postfix.org/postconf.5.html#smtpd_authorized_xforward_hosts


I read that too.  Can I specify $mynetworks ?

Quote:

Specify a list of network/netmask patterns, separated by commas and/or
whitespace. The mask specifies the number of bits in the network part
of a host address. You can also specify hostnames or .domain names (the
initial dot causes the domain to match any name below it),
"/file/name" or "type:table" patterns.  A "/file/name" pattern is
replaced by its contents; a "type:table" lookup table is matched when a
table entry matches a lookup string (the lookup result is ignored).
Continue long lines by starting the next line with whitespace. Specify
"!pattern" to exclude an address or network block from the list. The
form "!/file/name" is supported only in Postfix version 2.4 and later.

Note: IP version 6 address information must be specified inside [] in
the smtpd_authorized_xforward_hosts value, and in files specified with
"/file/name".  IP version 6 addresses contain the ":" character, and
would otherwise be confused with a "type:table" pattern.

As with the vast majority of Postfix parameters, "$variable" expansion
applies.  However, you generally should not use $mynetworks here.  More
typically that should just be "127.0.0.1" for allowing xforward data to
flow across a local SMTP content filter.  Even if some xforward systems
are truly separate upstream hosts, I'd recommend settings this separately
from mynetworks.


Thanks Viktor,

I did: postconf -e smtpd_authorized_xforward_hosts="127.0.0.1"

postfix reload

then

sendmail -i r...@htt-consult.com < 
/usr/share/doc/amavisd-new-2.10.1/test-messages/README


And amavis is complaining about Open relay.  So looks very much like 
amavis is just not getting this right.


Apr 24 18:04:58 z9m9z amavis[29479]: (29479-02) LMTP [127.0.0.1]:10024 
/var/spool/amavisd/tmp/amavis-20170424T102114-29479-kiPcalrA: 
<r...@z9m9z.test.htt-consult.com> -> <r...@htt-consult.com> SIZE=1424 
Received: from z9m9z.test.htt-consult.com ([127.0.0.1]) by localhost 
(z9m9z.test.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with 
LMTP for <r...@htt-consult.com>; Mon, 24 Apr 2017 18:04:58 -0400 (EDT)


Apr 24 18:04:58 z9m9z amavis[29479]: (29479-02) Checking: f4bZ8Ga89YJd 
[127.0.0.1] <r...@z9m9z.test.htt-consult.com> -> <r...@htt-consult.com>


Apr 24 18:04:58 z9m9z amavis[29479]: (29479-02) Open relay? Nonlocal 
recips but not originating: r...@htt-consult.com

Re: enabling xforward in ehlo

[Robert Moskowitz]

On 04/24/2017 11:35 PM, Viktor Dukhovni wrote:

On Apr 24, 2017, at 5:14 PM, Robert Moskowitz <r...@htt-consult.com> wrote:

I have spent some time today searching postfix documentation for enabling 
xforward in smtpd. I am not seeing it in the response to the EHLO when I telnet 
into localhost 25.  I cannot find any reference to what to put in master.cf (or 
main.cf) to do this.

http://www.postfix.org/postconf.5.html#smtpd_authorized_xforward_hosts


I read that too.  Can I specify $mynetworks ?

And I just checked again on my old host, and it does not show xforward 
on the ELHO, but does not exhibit this Open relay problem. Looking more 
to be some change in amavis.


But still interested in the way to work with 
smtpd_authorized_xforward_hosts because I don't get it from this explanation


thanks
.

enabling xforward in ehlo

[Robert Moskowitz]

Postfix 2.10.1

I have spent some time today searching postfix documentation for 
enabling xforward in smtpd. I am not seeing it in the response to the 
EHLO when I telnet into localhost 25.  I cannot find any reference to 
what to put in master.cf (or main.cf) to do this.


I THINK I need this to deal with amavis's policy bank of MYNET so that 
hosts within my network list will not get flagged as Open Relay.  (like 
a sendmail test from localhost).


All I have found is that the amavis entry in master.cf has:

amavis unix - - y - 2 lmtp -o lmtp_data_done_timeout=1200 -o 
lmtp_send_xforward_command=yes -o smtp_send_xforward_command=yes -o 
disable_dns_lookups=yes -o max_use=20



But that seems to be AFTER postfix sending the IP address into amavis.

thanks for the assistance

Re: startup process that rebuilds aliases.db?

[Robert Moskowitz]

On 04/20/2017 11:04 AM, Viktor Dukhovni wrote:

On Thu, Apr 20, 2017 at 03:30:58PM +0200, Patrick Ben Koetter wrote:


* Robert Moskowitz <r...@htt-consult.com>:

My system does not have a battery for the clock (like most armv7 SOCs), thus
I rely on that at some point in boot time, chronyd sets the time.  If a file
is updated prior to chronyd accomplishing its task (or network connectivity
is down), the file ends up with a timestamp of "Dec 31  1969".

I notice that occasionally, after a reboot, /etc/aliases.db reverts to this
time, and I have to run newaliases to fix it.  I suppose I could run touch
as well.

So is postfix startup rebuilding aliases.db, perhaps?  Is there some way to

It isn't. Something else must tamper your data.

While the "postfix start" command does not rebuild the aliases
database, it is possible that a more feature-rich start script
that invokes "postfix start" (provided by the O/S distribution)
does rebuild the aliases database.

You should be much more concerned about Postfix starting with
the wrong time than about the timestamp on the aliases.db file.

If the queue manager believes it is 1970, it is going to have a
hard time processing the queue correctly.  Make sure that the
Postfix start script does not run before the clock is set.

You could arrange for a small measure of sanity by setting the
clock to the modification time of some file that is updated at
shutdown if NTP or similar fails.  The RNG state save file
seems like a reasonable bet.


Here is what I have learned on the chronyd list:

"The recommended way to delay start of a service until the clock is
synchronized is to add "After=time-sync.target" to its unit file and
enable the chrony-wait service. It uses the chronyc waitsync command
to delay the time-sync target."





Another option is to refuse to start Postfix if the time is
before the date that your version of Postfix was released.

For example, with:

 $ postconf -dh mail_version
 3.1.3

we have:

 $ postconf -dh mail_release_date
 20161001

Re: startup process that rebuilds aliases.db?

[Robert Moskowitz]

On 04/20/2017 11:04 AM, Viktor Dukhovni wrote:

On Thu, Apr 20, 2017 at 03:30:58PM +0200, Patrick Ben Koetter wrote:


* Robert Moskowitz <r...@htt-consult.com>:

My system does not have a battery for the clock (like most armv7 SOCs), thus
I rely on that at some point in boot time, chronyd sets the time.  If a file
is updated prior to chronyd accomplishing its task (or network connectivity
is down), the file ends up with a timestamp of "Dec 31  1969".

I notice that occasionally, after a reboot, /etc/aliases.db reverts to this
time, and I have to run newaliases to fix it.  I suppose I could run touch
as well.

So is postfix startup rebuilding aliases.db, perhaps?  Is there some way to

It isn't. Something else must tamper your data.

While the "postfix start" command does not rebuild the aliases
database, it is possible that a more feature-rich start script
that invokes "postfix start" (provided by the O/S distribution)
does rebuild the aliases database.


I think I found it

more /usr/lib/systemd/system/postfix.service
[Unit]
Description=Postfix Mail Transport Agent
After=syslog.target network.target
Conflicts=sendmail.service exim.service

[Service]
Type=forking
PIDFile=/var/spool/postfix/pid/master.pid
EnvironmentFile=-/etc/sysconfig/network
ExecStartPre=-/usr/libexec/postfix/aliasesdb
ExecStartPre=-/usr/libexec/postfix/chroot-update
ExecStart=/usr/sbin/postfix start
ExecReload=/usr/sbin/postfix reload
ExecStop=/usr/sbin/postfix stop


That /usr/libexec/postfix/aliasesdb ?

Now if I can figure out that After line...



You should be much more concerned about Postfix starting with
the wrong time than about the timestamp on the aliases.db file.

If the queue manager believes it is 1970, it is going to have a
hard time processing the queue correctly.  Make sure that the
Postfix start script does not run before the clock is set.

You could arrange for a small measure of sanity by setting the
clock to the modification time of some file that is updated at
shutdown if NTP or similar fails.  The RNG state save file
seems like a reasonable bet.

Another option is to refuse to start Postfix if the time is
before the date that your version of Postfix was released.

For example, with:

 $ postconf -dh mail_version
 3.1.3

we have:

 $ postconf -dh mail_release_date
 20161001

startup process that rebuilds aliases.db?

[Robert Moskowitz]

My system does not have a battery for the clock (like most armv7 SOCs), 
thus I rely on that at some point in boot time, chronyd sets the time.  
If a file is updated prior to chronyd accomplishing its task (or network 
connectivity is down), the file ends up with a timestamp of "Dec 31  1969".


I notice that occasionally, after a reboot, /etc/aliases.db reverts to 
this time, and I have to run newaliases to fix it.  I suppose I could 
run touch as well.


So is postfix startup rebuilding aliases.db, perhaps?  Is there some way 
to delay postfix startup until after chronyd, or some other method to 
keep the date for aliases.db stable?


Note that aliases.db does not always revert to this date after startup, 
implying whatever is doing this either sometimes manages to run after 
chronyd, or not on every reboot.


thanks

Re: qmgr and content_filter

[Robert Moskowitz]

Viktor,

thanks for this explanation.  I was trying to figure it out from the man 
for gmgr, and I was getting, that gmgr was not what was triggering 
amavis.  Now I see I actually did get that right.


Onward!

On 04/19/2017 05:40 PM, Viktor Dukhovni wrote:

On Apr 19, 2017, at 5:24 PM, Robert Moskowitz <r...@htt-consult.com> wrote:

I am looking at maillog at an email generated by logwatch and see gmgr
calling amavis a few times.  So I am asking if gmgr should have the
content_filter = ?

No, because the queue manager does not create queue files, and the
content filter is written to the queue file by cleanup(8) if requested
by smtpd(8), pickup(8), ...

gmgr and content_filter

[Robert Moskowitz]

This is for a test system on Centos7

In main.cf I have:

content_filter = amavis:[127.0.0.1]:10024

Then in master.cf, I have an

-ocontent_filter =

For those services (like pickup) that I have figured out should not feed 
into amavis.


I am looking at maillog at an email generated by logwatch and see gmgr 
calling amavis a few times.  So I am asking if gmgr should have the 
content_filter = ?


I know I have other, amavis problems, but here are the maillog messages:


Apr 10 03:34:36 z9m9z postfix/pickup[1501]: C735BB25B: uid=0 from=
Apr 10 03:34:37 z9m9z postfix/cleanup[2077]: C735BB25B: 
message-id=<20170410073436.c735bb...@z9m9z.test.htt-consult.com>
Apr 10 03:34:37 z9m9z postfix/qmgr[3107]: C735BB25B: 
from=, size=5300, nrcpt=1 (queue active)
Apr 10 03:34:38 z9m9z amavis[2045]: (02045-11) NOTICE: reconnecting in 
response to: err=2006, HY000, DBD::mysql::st execute failed: MySQL 
server has gone away at (eval 129) line 172.
Apr 10 03:34:38 z9m9z amavis[2045]: (02045-11) LMTP [127.0.0.1]:10024 
/var/spool/amavisd/tmp/amavis-20170409T010521-02045-SZAIGFN5: 
 ->  
SIZE=5300 Received: from z9m9z.test.htt-consult.com ([127.0.0.1]) by 
localhost (z9m9z.test.htt-consult.com [127.0.0.1]) (amavisd-new, port 
10024) with LMTP for ; Mon, 10 Apr 2017 
03:34:38 -0400 (EDT)
Apr 10 03:34:38 z9m9z amavis[2045]: (02045-11) Checking: SGMxb1MYeOCZ 
[127.0.0.1]  -> 

Apr 10 03:34:38 z9m9z amavis[2045]: (02045-11) Open relay? Nonlocal 
recips but not originating: r...@z9m9z.test.htt-consult.com

Apr 10 03:34:51 z9m9z postfix/smtpd[2120]: connect from localhost[127.0.0.1]
Apr 10 03:34:52 z9m9z postfix/smtpd[2120]: 9D31F6B28: 
client=localhost[127.0.0.1]
Apr 10 03:34:52 z9m9z postfix/cleanup[2077]: 9D31F6B28: 
message-id=<20170410073436.c735bb...@z9m9z.test.htt-consult.com>
Apr 10 03:34:52 z9m9z postfix/smtpd[2120]: disconnect from 
localhost[127.0.0.1]
Apr 10 03:34:52 z9m9z amavis[2045]: (02045-11) SGMxb1MYeOCZ FWD from 
 -> , 
BODY=7BIT 250 2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: 
queued as 9D31F6B28
Apr 10 03:34:52 z9m9z postfix/qmgr[3107]: 9D31F6B28: 
from=, size=5795, nrcpt=1 (queue active)
Apr 10 03:34:52 z9m9z amavis[2045]: (02045-11) Passed CLEAN 
{RelayedOpenRelay}, [127.0.0.1]  -> 
, Message-ID: 
<20170410073436.c735bb...@z9m9z.test.htt-consult.com>, mail_id: 
SGMxb1MYeOCZ, Hits: -0.001, size: 5294, queued_as: 9D31F6B28, 14698 ms
Apr 10 03:34:52 z9m9z postfix/lmtp[2099]: C735BB25B: 
to=, orig_to=, 
relay=127.0.0.1[127.0.0.1]:10024, delay=30, delays=15/0.18/0.14/15, 
dsn=2.0.0, status=sent (250 2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250 
2.0.0 Ok: queued as 9D31F6B28)

Apr 10 03:34:52 z9m9z postfix/qmgr[3107]: C735BB25B: removed
Apr 10 03:34:52 z9m9z postfix/cleanup[2077]: E8ABF4F8A: 
message-id=<20170410073436.c735bb...@z9m9z.test.htt-consult.com>
Apr 10 03:34:53 z9m9z postfix/local[2126]: 9D31F6B28: 
to=, relay=local, delay=0.38, 
delays=0.09/0.2/0/0.09, dsn=2.0.0, status=sent (forwarded as E8ABF4F8A)
Apr 10 03:34:53 z9m9z postfix/qmgr[3107]: E8ABF4F8A: 
from=, size=5947, nrcpt=1 (queue active)

Apr 10 03:34:53 z9m9z postfix/qmgr[3107]: 9D31F6B28: removed
Apr 10 03:34:55 z9m9z postfix/smtp[2128]: Untrusted TLS connection 
established to z9m9z.htt-consult.com[50.253.254.3]:25: TLSv1.2 with 
cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Apr 10 03:34:57 z9m9z postfix/smtp[2128]: E8ABF4F8A: 
to=, orig_to=, 
relay=z9m9z.htt-consult.com[50.253.254.3]:25, delay=4.3, 
delays=0.05/0.11/1.9/2.2, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued 
as 2B51E6212F)

Apr 10 03:34:57 z9m9z postfix/qmgr[3107]: E8ABF4F8A: removed

Re: How is master.cf processed?

[Robert Moskowitz]

On 04/07/2017 04:39 PM, Wietse Venema wrote:

Robert Moskowitz:

I seem to have things running, now I am cleaning up my test setup before
building the new production server.

I perhaps got a little too fancy on modifying master.cf.  After I worked
out other packages like dovecot and roundcubemail, I started rethinking
how I alter master.cf for my needs.  It comes down to a couple questions:

I am working on the basis that this file is processed sequentially. Thus
if the file has:

submission inet n   -   n   -   -   smtpd

submission inet n   -   n   -   -   smtpd
  -o smtpd_recipient_restrictions=

It remembers only the last line. I suppose that this is documented
somewhere, but since this is almost 20 years old, memory is a little
hazy.


And I DID actually tried to research this first before asking!  But then 
my search foo is nothing to brag about...


Thanks for answering.

Wow, 20 years.  When did you 'ship' the first release of Postfix?

'95 was when I started running my own mail service.  It was on a dialup 
PPP link (rust.net) on an NT server.  No recollection what the software was.

Re: connecting to mysql socket

[Robert Moskowitz]

On 04/07/2017 01:38 PM, John Fawcett wrote:

On 04/07/2017 07:33 PM, Robert Moskowitz wrote:


On 04/07/2017 01:19 PM, Wietse Venema wrote:

Robert Moskowitz:

I solved my mysql access problem with dovecot; turned out it was trying
a tcp connection and mysql is not listening on tcp.  Fixed that to use
mysql.sock.

So this got me digging into how postfix was successfully accessing
mysql.  I see in my various .cf files that access mysql that I have:

host= localhost

And reading the docs (what read the docs?), this tells postfix to
connect to mysql via the default UNIX domain socket.  How does it know
what the file handle is?  It seems to be working...

It doesn't. Postfix makes all MySQL requests through the mysql
library.  For best results, use the library that matches the server
(so that they use the same default socket, among other things).

I read this response to just leave it as host = localhost, as
everything is local on the one server.



should be

hosts = localhost


It is.  I should have cut and paste instead of typing from memory...

thanks

How is master.cf processed?

[Robert Moskowitz]

I seem to have things running, now I am cleaning up my test setup before 
building the new production server.


I perhaps got a little too fancy on modifying master.cf.  After I worked 
out other packages like dovecot and roundcubemail, I started rethinking 
how I alter master.cf for my needs.  It comes down to a couple questions:


I am working on the basis that this file is processed sequentially. Thus 
if the file has:


submission inet n   -   n   -   -   smtpd

submission inet n   -   n   -   -   smtpd
-o smtpd_recipient_restrictions=

the 2nd submission with its option is what is enforce.  But what if the 
case changes an option or leaves out an option.  For example purposes:


submission inet n   -   n   -   -   smtpd
-o smtpd_recipient_restrictions=permit_sasl_authenticated,reject
-o smtpd_tls_security_level=encrypt

submission inet n   -   n   -   -   smtpd
-o smtpd_recipient_restrictions=

In this case smtpd_recipient_restrictions is now null, but what is the 
state of smtpd_tls_security_level?  back to default?


thanks

Re: connecting to mysql socket

[Robert Moskowitz]

On 04/07/2017 01:19 PM, Wietse Venema wrote:

Robert Moskowitz:

I solved my mysql access problem with dovecot; turned out it was trying
a tcp connection and mysql is not listening on tcp.  Fixed that to use
mysql.sock.

So this got me digging into how postfix was successfully accessing
mysql.  I see in my various .cf files that access mysql that I have:

host= localhost

And reading the docs (what read the docs?), this tells postfix to
connect to mysql via the default UNIX domain socket.  How does it know
what the file handle is?  It seems to be working...

It doesn't. Postfix makes all MySQL requests through the mysql
library.  For best results, use the library that matches the server
(so that they use the same default socket, among other things).


I read this response to just leave it as host = localhost, as everything 
is local on the one server.

connecting to mysql socket

[Robert Moskowitz]

I solved my mysql access problem with dovecot; turned out it was trying 
a tcp connection and mysql is not listening on tcp.  Fixed that to use 
mysql.sock.


So this got me digging into how postfix was successfully accessing 
mysql.  I see in my various .cf files that access mysql that I have:


host= localhost

And reading the docs (what read the docs?), this tells postfix to 
connect to mysql via the default UNIX domain socket.  How does it know 
what the file handle is?  It seems to be working...


Should I force it with:

host = unix:/var/lib/mysql/mysql.sock

instead?  Which is the sock that I am successfully using with dovecot 
and amavis.


Plus it better documents the behavior instead of relying on reading the 
docs...


thanks

Re: Postfix impatient with mysql?

[Robert Moskowitz]

On 04/06/2017 02:17 PM, John Stoffel wrote:

Robert> It seems postfix is impatient with connecting with mysql, as I see in
Robert> maillog entries like:

Robert> Apr  6 11:48:30 z9m9z dovecot: dict: Error: mysql(localhost): Connect
Robert> failed to database (postfix): Can't connect to local MySQL server
Robert> through socket '/var/lib/mysql/mysql.sock' (13) - waiting for 5 seconds
Robert> before retry
Robert> Apr  6 11:48:35 z9m9z dovecot: dict: Error: mysql(localhost): Connect
Robert> failed to database (postfix): Can't connect to local MySQL server
Robert> through socket '/var/lib/mysql/mysql.sock' (13) - waiting for 25 seconds
Robert> before retry

Robert> I suspect it does connect eventually.  This is a test system with only
Robert> 1GB of memory and free reports:

Robert>totalusedfree  shared buff/cache
Robert> available
Robert> Mem:1025484  696344   24556 21528  304584  
251552
Robert> Swap:524284   92168  432116


Robert> The production box has 2GB, so if the problem is mysql is
Robert> swapping out, that will be 'fixed', if it is processor, well
Robert> this is an ARMv7 duo core, as is the production box.  I am
Robert> considering buying the new quad core.

Robert> Is there anything I can do to get postfix more patient with
Robert> mysql, or just ignore there messages?

Just as a side note, I setup my home server with dovecot, postfix,
mysql and I ended up removing mysql because it was a memory pig for a
not-very big install.  In your case, if you're running on an ARMv7
dual CPU box, it also isn't too big so I'd prboably not bother.
sqlite or even flat files should be more than performant enough for
your needs.


I support virtual domains and use postfixadmin.

Granted not many domains and < 10,000 messages per day.

I am currently running on a CubieTruck (duo core, 2GB, ARMv7) with 
Redsleeve 6 (Centos 6 clone) and time-matching componenets.


My development to replace it is on a Cubieboard2 (same as above, but 
1GB) with Centos 7.


I don't get any of these messages on the current server.  So perhaps it 
is just a memory thing.  I will start testing on another CubieTruck soon 
and that will show if memory is the bottleneck.

Oops - Re: Postfix impatient with mysql?

[Robert Moskowitz]

I should get new glasses...

That is database postfix by dovecot.  Sigh.

On 04/06/2017 12:01 PM, wilfried.es...@essignetz.de wrote:

Possibly you should ask some dovecot people. The loglines you provided,
show processname "dovecot", not postfix.


Willi


Am 06.04.2017 um 17:54 schrieb Robert Moskowitz:

It seems postfix is impatient with connecting with mysql, as I see in
maillog entries like:

Apr  6 11:48:30 z9m9z dovecot: dict: Error: mysql(localhost): Connect
failed to database (postfix): Can't connect to local MySQL server
through socket '/var/lib/mysql/mysql.sock' (13) - waiting for 5 seconds
before retry
Apr  6 11:48:35 z9m9z dovecot: dict: Error: mysql(localhost): Connect
failed to database (postfix): Can't connect to local MySQL server
through socket '/var/lib/mysql/mysql.sock' (13) - waiting for 25 seconds
before retry

I suspect it does connect eventually.  This is a test system with only
1GB of memory and free reports:

totalusedfree  shared buff/cache
available
Mem:1025484  696344   24556 21528  304584  251552
Swap:524284   92168  432116


The production box has 2GB, so if the problem is mysql is swapping out,
that will be 'fixed', if it is processor, well this is an ARMv7 duo
core, as is the production box.  I am considering buying the new quad core.

Is there anything I can do to get postfix more patient with mysql, or
just ignore there messages?

thank you

Postfix impatient with mysql?

[Robert Moskowitz]

It seems postfix is impatient with connecting with mysql, as I see in 
maillog entries like:


Apr  6 11:48:30 z9m9z dovecot: dict: Error: mysql(localhost): Connect 
failed to database (postfix): Can't connect to local MySQL server 
through socket '/var/lib/mysql/mysql.sock' (13) - waiting for 5 seconds 
before retry
Apr  6 11:48:35 z9m9z dovecot: dict: Error: mysql(localhost): Connect 
failed to database (postfix): Can't connect to local MySQL server 
through socket '/var/lib/mysql/mysql.sock' (13) - waiting for 25 seconds 
before retry


I suspect it does connect eventually.  This is a test system with only 
1GB of memory and free reports:


  totalusedfree  shared buff/cache   
available

Mem:1025484  696344   24556 21528  304584  251552
Swap:524284   92168  432116


The production box has 2GB, so if the problem is mysql is swapping out, 
that will be 'fixed', if it is processor, well this is an ARMv7 duo 
core, as is the production box.  I am considering buying the new quad core.


Is there anything I can do to get postfix more patient with mysql, or 
just ignore there messages?


thank you

Re: Question on embedded variables in postconf command

[Robert Moskowitz]

Ah,

On 03/09/2017 10:13 AM, Viktor Dukhovni wrote:

On Mar 9, 2017, at 9:54 AM, Robert Moskowitz <r...@htt-consult.com> wrote:

I have modified my guide by setting interactive variables in the beginning and 
then using them throughout, so that it is not necessary (or much less) to 
modify stuff.  I came up with:

eval $(echo "postconf -e 'mydomain = "$your_domain_tld"'")
eval $(echo "postconf -e 'myhostname = "$your_host_tld"'")

The variables your_domain_tld and your_host_tld are used a lot in this guide to 
customize conf files and such.

Might be a slicker way, but this works...

That's rather convoluted, what's wrong with:

  postconf -e "mydomain = $your_domain_tld"


There appears to be a difference between what you show above and what I 
tested:


postconf -e 'mydomain = $your_domain_tld'

The single quote results in:

mydomain = $your_domain_tld

So I did a little googling and learned the difference:

http://stackoverflow.com/questions/6697753/difference-between-single-and-double-quotes-in-bash

This time around I am really trying to do things smarter and am 
expanding my rather limited skill set.



  postconf -e "myhostname = $your_host_tld"

Or when doing both:

  postconf -e \
"mydomain = $your_domain_tld" \
"myhostname = $your_host_tld"

which takes considerably less time, because Postfix likes to
avoid reading "hot" configuration files that have been modified
less than two seconds ago and may be in an intermediate state.

So the configuration reader sleeps for 300ms and retries, waiting
for the file to "cool down".  Therefore, modifying paramaters one
at a time takes around 1.5 seconds per parameter.

unused parameter: virtual_mailbox_limit_maps

[Robert Moskowitz]

I found one article:

https://www.howtoforge.com/community/threads/postfix-warning-undefined-parameter-virtual_mailbox_limit_maps.71474/

that says it is not required anymore.  To remove it.  I am *assuming* 
that I then also remove:


/etc/postfix/mysql-virtual_mailbox_limit_maps.cf

I looked around and did not see anywhere it is being used.

Seems this is a hang over from long ago.  Old server does not have this 
option, but still has the file.


?

thanks

Re: Question on embedded variables in postconf command

[Robert Moskowitz]

Sorry, Viktor,

I was not clear in my intent.

This is for a guide that uses a number of interactive environment 
variables to build lots of conf files that are needed, it seems, for a 
mail server.


So the variables are long gone when the server is up and running. Thus 
for main.cf, I want to hard code the value of those variables into 
mydomain and myhostname.  The eval with echo command is run through the 
guide to execute these postconf commands to have the desired main.cf.  
Rather than what I have seen in many other guides, where they supply a 
main.cf to replace the shipped main.cf.  I learned here 4 years ago why 
that is a 'bad thing'.


But thanks for the insight.

On 03/09/2017 10:13 AM, Viktor Dukhovni wrote:

On Mar 9, 2017, at 9:54 AM, Robert Moskowitz <r...@htt-consult.com> wrote:

I have modified my guide by setting interactive variables in the beginning and 
then using them throughout, so that it is not necessary (or much less) to 
modify stuff.  I came up with:

eval $(echo "postconf -e 'mydomain = "$your_domain_tld"'")
eval $(echo "postconf -e 'myhostname = "$your_host_tld"'")

The variables your_domain_tld and your_host_tld are used a lot in this guide to 
customize conf files and such.

Might be a slicker way, but this works...

That's rather convoluted, what's wrong with:

  postconf -e "mydomain = $your_domain_tld"
  postconf -e "myhostname = $your_host_tld"

Or when doing both:

  postconf -e \
"mydomain = $your_domain_tld" \
"myhostname = $your_host_tld"

which takes considerably less time, because Postfix likes to
avoid reading "hot" configuration files that have been modified
less than two seconds ago and may be in an intermediate state.

So the configuration reader sleeps for 300ms and retries, waiting
for the file to "cool down".  Therefore, modifying paramaters one
at a time takes around 1.5 seconds per parameter.

Re: Question on embedded variables in postconf command

[Robert Moskowitz]

On 03/07/2017 02:43 PM, Peter wrote:

On 08/03/17 08:00, Robert Moskowitz wrote:

After a bit of reflection, I may have asked the wrong question. Perhaps
a better question is does the substitution take place on processing the
option?

It would take place at runtime (I believe).  If you want it to hard-code
the substitution into main.cf you could do something like this:

postconf "smtpd_tls_key_file = /etc/pki/private/$(postconf -h
myhostname).key"


This did not quite work, at least in using interactive variables.  I 
have modified my guide by setting interactive variables in the beginning 
and then using them throughout, so that it is not necessary (or much 
less) to modify stuff.  I came up with:


eval $(echo "postconf -e 'mydomain = "$your_domain_tld"'")
eval $(echo "postconf -e 'myhostname = "$your_host_tld"'")

The variables your_domain_tld and your_host_tld are used a lot in this 
guide to customize conf files and such.


Might be a slicker way, but this works...

Re: Setting amavis content_filter in main.cf

[Robert Moskowitz]

Thank you for this.  I will review it.

One comment I got over on the amavis list was that not to filter from 
localhost.  Like mail sent from logwatch.  How does this handle 
localhost sent mail?




On 03/09/2017 06:01 AM, chaouche yacine wrote:

Hello Robert,

Here's my setup :


in main.cf :

content_filter = amavis:[127.0.0.1]:10024

This tells postfix to use the amavis "service" (defined later in master.cf) to 
send all incoming mails to localhost port 10024





in master.cf :
amavis unix - - - - 2 smtp
 -o smtp_data_done_timeout=1200
 -o smtp_send_xforward_command=yes



this defines the amavis "service" as a unix socket named amavis. It is 
delivering e-mail with the SMTP command to amavis, the mail filtering software.


Once amavis is done scanning the e-mail, it will reinject them to the postfix 
queue, usually on port 10025. So one must also instruct postfix to listen on 
that port for incoming e-mail (from amavis). This is also done in master.cf :


127.0.0.1:10025 inet n - - - - smtpd
-o content_filter=
-o local_recipient_maps=
-o relay_recipient_maps=
-o smtpd_restriction_classes=
-o smtpd_client_restrictions=
-o smtpd_helo_restrictions=
#-o smtpd_sender_restrictions=
-o smtpd_recipient_restrictions=permit_mynetworks,reject
-o mynetworks=127.0.0.0/8
-o strict_rfc821_envelopes=yes
-o receive_override_options=no_unknown_recipient_checks,no_header_body_checks


This defines a new Internet socket for the smtpd dameon listening for requests 
on 127.0.0.1 port 10025.

Notice that this service doesn't use a content_filter because :

1. The e-mail is coming from already filtered from amavis so there's no need to 
filter it again.
2. If the -o content_filter is ommited, the content_filter defined in main.cf 
will apply, which means postfix will reinject mail to amavis, which will filter 
again and send to postfix, which will send to amavis... (loop) see 
http://i.imgur.com/aUAsuR1.png for a diagram.


On Wednesday, March 8, 2017 10:07 PM, Robert Moskowitz <r...@htt-consult.com> 
wrote:



As I dig into this more, I can see why not to make content_filter
global.  Unless there is some way not to have it work with localhost
connections.


On 03/08/2017 03:03 PM, Robert Moskowitz wrote:

I am reading the amavis-new readme for postfix.

It almost reads like main.cf should have:

content_filter=amavisfeed:[127.0.0.1]:10024

rather than how I see it all over in master.cf.  Its presence as an
option in master.cf is very inconsistent.

Are there services in master.cf that should not have a content_filter
to amavisfeed?

thank you

Re: Setting amavis content_filter in main.cf

[Robert Moskowitz]

As I dig into this more, I can see why not to make content_filter 
global.  Unless there is some way not to have it work with localhost 
connections.


On 03/08/2017 03:03 PM, Robert Moskowitz wrote:

I am reading the amavis-new readme for postfix.

It almost reads like main.cf should have:

content_filter=amavisfeed:[127.0.0.1]:10024

rather than how I see it all over in master.cf.  Its presence as an 
option in master.cf is very inconsistent.


Are there services in master.cf that should not have a content_filter 
to amavisfeed?


thank you

Setting amavis content_filter in main.cf

[Robert Moskowitz]

I am reading the amavis-new readme for postfix.

It almost reads like main.cf should have:

content_filter=amavisfeed:[127.0.0.1]:10024

rather than how I see it all over in master.cf.  Its presence as an 
option in master.cf is very inconsistent.


Are there services in master.cf that should not have a content_filter to 
amavisfeed?


thank you

Re: Using postconf to manage master.cf

[Robert Moskowitz]

Wietse,

thank you for your response.

On 03/08/2017 10:44 AM, Wietse Venema wrote:

Robert Moskowitz:

But this is not the point.  In fact, if there is no guidance on how to
use postconf for managing master.cf, it really does not matter which
version of postfix I use.  Just maintain master.cf as we always have.

There is a nice http://www.postfix.org/postconf.5.html write up on
maintaining main.cf, but not on master.cf.

There is (obviously) no such guidance with Postfix releases that
pre-date the support to edit master.cf. Only Postfix versions that
support master.cf editing document these features (in the postconf(1)
manpage).

In short, you can list master.cf as a sequence of name=value pairs,
and you can specify name=value pairs to change master.cf.


When I look at man postconf, -o only updates main.cf.  -M is only for 
reporting what is in master.cf.



These features were added to facilitate automated configuration
management (Puppet, Chef, etc.). When every setting looks like a
name=value pair, it can be managed by programs that don't need to
understand Postfix configuration syntax.

It's probably overkill for a small site, but it's one of the attempts
to bring Postfix into the 21st century (along with JSON queue listings).


And so I stay with the old way of using 'cat >> master.cf' and sed to 
update.  That still works and is 'good enough' for my goals. Just wanted 
to stay current with what is available in the release provided by the 
Centos/Redhat maintainers.


Again, thank you for responding and thank you for this great product.

BTW, I am working in the IETF I2NSF workgroup where we are defining 
architecture and protocols to maintain Network Security Functions. Some 
of those will end up in remotely managed updates to Postfix. So on that 
level, I get what you are doing.


take care.

Re: Using postconf to manage master.cf

[Robert Moskowitz]

Viktor,

thanks for your reply.  More below.

On 03/08/2017 10:34 AM, Viktor Dukhovni wrote:

On Mar 8, 2017, at 8:16 AM, Robert Moskowitz <r...@htt-consult.com> wrote:

But this is not the point.  In fact, if there is no guidance on how to
use postconf for managing master.cf, it really does not matter which
version of postfix I use.  Just maintain master.cf as we always have.

All the postconf(1) command options are documented.  Just type:

man postconf

to see what command options your version supports.  You can also
look at:

http://www.postfix.org/postconf.1.html


And that is what I did.  I saw what the options were, but no practical 
examples of them in use.  That is what I meant by 'guidance'.  The 
Postfix online manual has a lot of guidance on how to actually do things 
to Postfix to get it to do many valuable things.



which documents the latest version, and does its best to list
the first release in which various features appeared.  To see
the document for older releases, say 2.10, you can leverage github:


http://htmlpreview.github.io/?https://github.com/vdukhovni/postfix/blob/postfix-2.10/postfix/html/postconf.1.html


There is a nice http://www.postfix.org/postconf.5.html write up on maintaining 
main.cf, but not on master.cf.

The documentation in postconf(1) should be sufficient.  For 2.10 you have:

Managing master.cf:

postconf [-fMovx] [-c config_dir] [service ...]

...

-f Fold  long lines when printing main.cf or master.cf
   configuration file entries, for human  readability.

   This  feature  is  available  with  Postfix 2.9 and
   later.

-M Show  master.cf  file  contents  instead of main.cf

   file contents.  Specify -Mf  to fold long lines  for
   human readability.

   If service ...  is specified, only the matching ser-
   vices will be output. For  example,  "postconf  -Mf
   inet"  will  output all services that listen on the
   network.

   Specify zero or more arguments, each  with  a  ser-
   vice-type  name (inet, unix, fifo, or pass) or with
   a service-name.service-type  pair,  where  service-
   name is the first field of a master.cf  entry.

   This  feature  is  available  with  Postfix 2.9 and
   later.

-o name=value
   Override main.cf parameter settings.

   This  feature  is  available  with Postfix 2.10 and
   later.

-v Enable verbose logging for debugging purposes. Mul-
   tiple -v options  make  the software increasingly
   verbose.

-x Expand $name in main.cf or master.cf parameter val-
   ues. The expansion is recursive.

   This  feature  is  available  with Postfix 2.10 and
   later.

So, in Postfix 2.10, you can display [selected] master.cf entries
or update overrides (-o parameters) for a given service.


But -o does not actually update master.cf.  That seems to be what -P 
does in Postfix 2.11.



The master.cf modification features are much more extensive in
later releases.


And that is what I was looking for.  I would have thought that somewhere 
there would be use examples of say, adding submission support into 
master.cf using postconf.  I actually did find one such blog:


https://www.mind-it.info/2014/02/20/change-postfix-master-cf-postconf/

But the blogger does not state what version he used.  Obviously it was 
at least 2.11.


Again thank you.

Re: Using postconf to manage master.cf

[Robert Moskowitz]

On 03/08/2017 05:57 AM, Postfix User wrote:

On Tue, 7 Mar 2017 23:54:36 -0500, Robert Moskowitz stated:


I am back to building a new mailserver.  I am using Centos7 which has
postfix 2.10.1

Back some 4 years ago there was a thread here to add support to
postconf to manage master.cf.  From

http://www.postfix.org/postconf.1.html

It seems that there are now options here for master.cf, but I cannot
find any guidance on using this.  My search foo is notoriously weak;
my searching this list has not found any discussion on this since 1/13.

I found one blog that uses 'postconf -P', but I see that the -P option
came out in postfix 2.11

Is there guidance to using postconf to manage master.cf?

thank you

According to the documentation located on
ftp://ftp.porcupine.org/mirrors/postfix-release/index.html
the 2.10.1 version is no longer supported. I know nothing about
Centos7; however, wouldn't it be possible to use a newer version of
Postfix, the latest being Postfix 3.2 I believe.


This is one of the 'joys' of working with Centos/Redhat.  You are always 
'back-leveled'.  But then the work is on them to apply patches and keep 
rpms 'safe'.  All I have to do, is update.  Thus the only real 
justification is if there are functions/features really needed.  IMNSHO.


But this is not the point.  In fact, if there is no guidance on how to 
use postconf for managing master.cf, it really does not matter which 
version of postfix I use.  Just maintain master.cf as we always have.


There is a nice http://www.postfix.org/postconf.5.html write up on 
maintaining main.cf, but not on master.cf.

Using postconf to manage master.cf

[Robert Moskowitz]

I am back to building a new mailserver.  I am using Centos7 which has 
postfix 2.10.1


Back some 4 years ago there was a thread here to add support to postconf 
to manage master.cf.  From


http://www.postfix.org/postconf.1.html

It seems that there are now options here for master.cf, but I cannot 
find any guidance on using this.  My search foo is notoriously weak; my 
searching this list has not found any discussion on this since 1/13.


I found one blog that uses 'postconf -P', but I see that the -P option 
came out in postfix 2.11


Is there guidance to using postconf to manage master.cf?

thank you

Re: Question on embedded variables in postconf command

[Robert Moskowitz]

On 03/07/2017 02:43 PM, Peter wrote:

On 08/03/17 08:00, Robert Moskowitz wrote:

After a bit of reflection, I may have asked the wrong question. Perhaps
a better question is does the substitution take place on processing the
option?

It would take place at runtime (I believe).  If you want it to hard-code
the substitution into main.cf you could do something like this:

postconf "smtpd_tls_key_file = /etc/pki/private/$(postconf -h
myhostname).key"


Oh, that is very interesting!  Took me a bit looking at it to get what 
you did, but very nice.


In this case I will keep it 'soft' so if I were to change my host name 
and my cert file, I would only have to make the change in one place.


thanks

Re: Question on embedded variables in postconf command

[Robert Moskowitz]

On 03/07/2017 02:19 PM, Christian Kivalo wrote:


Am 7. März 2017 20:00:55 MEZ schrieb Robert Moskowitz <r...@htt-consult.com>:

After a bit of reflection, I may have asked the wrong question. Perhaps

a better question is does the substitution take place on processing the

option?

What about testing the assumption? Build the configuration and try to make a 
tls secured connection, it either works or you will see the error in your  logs.


I am days away for a working server.  Well, maybe I can test on 
another...  hmmm.


I plod along testing each build step out, going back to checkpoints and 
moving forward again.  Now it is the Postfix configs.



Just changed my configuration to use $myhostname variable for the cert name 
filename and that works very well. Thanks for the idea.


Thanks for trying it out!  I am working on minimizing the places where I 
have to customize my howto, so that I can better remember what I did 
years ago.  Plus share it with others.


And this would apply also to smtpd_tls_cert_file.


thanks

On 03/07/2017 01:59 PM, Robert Moskowitz wrote:

Is there a way to get the following:

postconf -e 'smtpd_tls_key_file =

/etc/pki/tls/private/$myhostname.key'

To work and substitute the value for $myhostname?

I am building a new server and writing up my scripts and I am trying
to adhere to the lessons I learned here some 2+ years ago. And trying
to be better than I was then...


Thank you.

Re: Question on embedded variables in postconf command

[Robert Moskowitz]

After a bit of reflection, I may have asked the wrong question. Perhaps 
a better question is does the substitution take place on processing the 
option?


thanks

On 03/07/2017 01:59 PM, Robert Moskowitz wrote:

Is there a way to get the following:

postconf -e 'smtpd_tls_key_file = /etc/pki/tls/private/$myhostname.key'

To work and substitute the value for $myhostname?

I am building a new server and writing up my scripts and I am trying 
to adhere to the lessons I learned here some 2+ years ago. And trying 
to be better than I was then...



Thank you.

Question on embedded variables in postconf command

[Robert Moskowitz]

Is there a way to get the following:

postconf -e 'smtpd_tls_key_file = /etc/pki/tls/private/$myhostname.key'

To work and substitute the value for $myhostname?

I am building a new server and writing up my scripts and I am trying to 
adhere to the lessons I learned here some 2+ years ago.  And trying to 
be better than I was then...



Thank you.

Working around recalcitrant ISP wrt rDNS

[Robert Moskowitz]

I have been 'working' with my new ISP for a couple weeks to get the rDNS 
setup for my server move (I am changing ISPs for a number of reasons).  
I was assured on signing that setting up rDNS was 'easy'; it is not.  
DIGing up the SOA on my IP rDNS tends to indicate that they have not 
updated that zone for many months.


Anyway,,,

A friend using the same ISP 'solved' this by changing his SMTP server to 
say the mail for his domain is ok to come from the ISP PTR value.  So 
let's say that:


My server is:  z9m9z.htt-consult.com

And further assume that the reverse for the address where I want to move 
it to has a PTR of


9.254.253.50.in-addr.arpa. 3600INPTR 
50-253-254-9-static.hfc.comcastbusiness.net.


And that 50-253-254-9-static.hfc.comcastbusiness.net has no RR (e.g. A 
or CNAME).


Is there someway to get postfix to provide the needed inforation to the 
recipient MTA that this is OK and valid?


I am asking, but I suspect that even if I send out things OK, there will 
be MTAs out there that will not let their clients send mail to me as my 
rDNS does not match.


I am pushing the ISP that will remain unnamed.  (oops.  :)  )  I was 
told that 'they are working on it'.  Meanwhile I am paying double as I 
cannot migrate my server.


I will be pleased if there is a real workaround, but not overly 
disappointed if the only way out is through.

Re: Working around recalcitrant ISP wrt rDNS

[Robert Moskowitz]

On 02/04/2015 03:46 PM, Noel Jones wrote:

On 2/4/2015 1:47 PM, Robert Moskowitz wrote:

I have been 'working' with my new ISP for a couple weeks to get the
rDNS setup for my server move (I am changing ISPs for a number of
reasons).  I was assured on signing that setting up rDNS was 'easy';
it is not.  DIGing up the SOA on my IP rDNS tends to indicate that
they have not updated that zone for many months.

Anyway,,,

A friend using the same ISP 'solved' this by changing his SMTP
server to say the mail for his domain is ok to come from the ISP PTR
value.  So let's say that:

My server is:  z9m9z.htt-consult.com

And further assume that the reverse for the address where I want to
move it to has a PTR of

9.254.253.50.in-addr.arpa. 3600INPTR
50-253-254-9-static.hfc.comcastbusiness.net.

And that 50-253-254-9-static.hfc.comcastbusiness.net has no RR (e.g.
A or CNAME).

Is there someway to get postfix to provide the needed inforation to
the recipient MTA that this is OK and valid?

I am asking, but I suspect that even if I send out things OK, there
will be MTAs out there that will not let their clients send mail to
me as my rDNS does not match.

I am pushing the ISP that will remain unnamed.  (oops.  :)  )  I was
told that 'they are working on it'.  Meanwhile I am paying double as
I cannot migrate my server.

I will be pleased if there is a real workaround, but not overly
disappointed if the only way out is through.




Don't worry about *receiving* mail.

Other systems sending you mail don't care a bit about what the name
of your MX server is, or what kind of IP it's hosted on, as long as
the MX name resolves to the correct IP.  Feel free to reuse your
current z9m9z.htt-consult.com as an MX name, or use something
totally different.


There are potential problems with *sending* mail.

All the comcast business IPs that I know of already have proper
FCrDNS.  This is necessary to communicate with sites that use
reject_unknown_client_hostname or similar.


If they run your domain (at an additional cost), they take care of the 
rDNS.  If not, you have to put a request in that gets bounced around a 
couple of times until someone figures out what you are asking about.



If your new IP's PTR has no matching A record, get that solved first
before you tackle trying to get a custom PTR.  This should be an
easier problem to fix.


I will change my A record only after the PTR is created.  If I change my 
A record first by adding it as a second A record, any server that tries 
it will get a connection failure as I have not moved my system yet.  If 
I change my A record and move the system before the rDNS is done, I am 
back to that mess I got myself in before with a bad rDNS floating around.


The only way I see for a smooth migration of an existing server is:

1) setup rDNS - this hurts no one, as since nothing is on the address, 
no one is doing an rDNS lookup.

2) move the server and change forward DNS (set TTL low at first).

Done.  (restore TTL to longer value)


Once you have FCrDNS (even with an unwanted PTR name), you should be
able to safely move.  Do some testing -- just hook some PC up to the
new connection and use telnet (or the very handy mini_smtp tool) to
send some test mails directly to various servers.


I have a web server already over there that I can test from.  What 
little I do web wise is not bothered by no rDNS.  Now moving the DNS 
server itself will be a fun adventure.  I already have all the zone 
files redone for the move.



Configure postfix with a HELO name (smtp_helo_name) something like
z9m9z.htt-consult.com rather than the more technically correct PTR
name.  Make sure the HELO hostname has an A record pointing to your
IP.  (bonus points for a name containing smtp, e?mail, mx, mta,
etc.) This helps you look more like a mail server and less like a bot.

Make sure you have an SPF record including your IP.  If you use the
same IP for sending and receiving, just include the spf mx key.
(looks as if you have that already... good)

Re: Working around recalcitrant ISP wrt rDNS

[Robert Moskowitz]

On 02/04/2015 03:51 PM, Noel Jones wrote:
Which reminds me that the OP should register his domain and IP on 
dnswl.org (free and easy). -- Noel Jones 


thanks for the tip.  Just one more action item.

tcp port 645 - smtps?

[Robert Moskowitz]

I see a rule on my firewall defining a custom port of 645 as smtps, yet 
I cannot find anything at iana on this and googling does not explain 
it.  'netstat -na|grep 645' does not show anything listening on this 
port.  No telling how many servers ago this rule got added.


Is this some old bogus holdover, or something I should be using?

Still trying to figure out why yahoo won't email me...

And Ident - port 113

[Robert Moskowitz]

I also have ident - port 113 open on the firewall.  But not only is it 
not open on the server's firewall, I don't see a listen for it with 
'netstat -na|grep113'


I do recall that ident was one thing some MTAs wanted.  Is that still 
so?  And if so, should I see a listen on it?

Re: And Ident - port 113

[Robert Moskowitz]

On 12/05/2014 08:03 AM, li...@rhsoft.net wrote:



Am 05.12.2014 um 14:00 schrieb Robert Moskowitz:

I also have ident - port 113 open on the firewall.  But not only is it
not open on the server's firewall, I don't see a listen for it with
'netstat -na|grep113'

I do recall that ident was one thing some MTAs wanted.  Is that still
so?  And if so, should I see a listen on it?


that is all *not* postfix related and for incoming mail you don#t need 
anything than port 25


how is *that* related to mail?
http://en.wikipedia.org/wiki/Ident_protocol


I am having to page back at least 3 mailservers ago.  I could replug in 
my last one (which I have not erased yet) to see if it used it, but 
definitely some time ago I remember having to enable ident for mail.  
Now was it for MTAs or clients?  I am going back at least 6 years here.  
I doubt if I can find notes for it.


And yes, ident could query things like port 25 to see if it is mail.

Thinking back, now this may go back over 10 years and just being carried 
forward.  And my yahoo problem could well be they don't like the spf 
rule that google wanted...  Waiting for the mail admin to respond to the 
ticket I opened last night.

Re: And Ident - port 113

[Robert Moskowitz]

On 12/05/2014 08:15 AM, lst_ho...@kwsoft.de wrote:


Zitat von li...@rhsoft.net:


Am 05.12.2014 um 14:00 schrieb Robert Moskowitz:

I also have ident - port 113 open on the firewall.  But not only is it
not open on the server's firewall, I don't see a listen for it with
'netstat -na|grep113'

I do recall that ident was one thing some MTAs wanted.  Is that still
so?  And if so, should I see a listen on it?


that is all *not* postfix related and for incoming mail you don#t 
need anything than port 25


how is *that* related to mail?
http://en.wikipedia.org/wiki/Ident_protocol


There was a time some 20 years ago where E-Mail was a Unix thing only, 
where servers try to identify the remote connecting with a ident 
call and stall the connection until either succeed or timeout. This is 
ancient behaviour not seen anymore, we have disabled the reject for 
ident some 3 years ago.


And I brought up my first mailserver in '95 on an NT server. Probably 
goes back that far! Just carried it forward all these years.  Well 
nothing is listening...

Re: And Ident - port 113

[Robert Moskowitz]

On 12/05/2014 08:16 AM, li...@rhsoft.net wrote:


Am 05.12.2014 um 14:12 schrieb Robert Moskowitz:

On 12/05/2014 08:03 AM, li...@rhsoft.net wrote:

Am 05.12.2014 um 14:00 schrieb Robert Moskowitz:

I also have ident - port 113 open on the firewall.  But not only is it
not open on the server's firewall, I don't see a listen for it with
'netstat -na|grep113'

I do recall that ident was one thing some MTAs wanted.  Is that still
so?  And if so, should I see a listen on it?


that is all *not* postfix related and for incoming mail you don#t need
anything than port 25

how is *that* related to mail?
http://en.wikipedia.org/wiki/Ident_protocol


I am having to page back at least 3 mailservers ago.  I could replug in
my last one (which I have not erased yet) to see if it used it, but
definitely some time ago I remember having to enable ident for mail. Now
was it for MTAs or clients?  I am going back at least 6 years here. I
doubt if I can find notes for it.


if at all then for *clients*


And yes, ident could query things like port 25 to see if it is mail.

Thinking back, now this may go back over 10 years and just being carried
forward.  And my yahoo problem could well be they don't like the spf
rule that google wanted...


nonsense - the thread you refer to is No mail from yahoo or ymail
*from yahoo* = incoming mail
SPF = mail *you send* to the outside world


And that is what I read too.  So what is yahoo seeing that I am not 
seeing any connections from them?  I have read all their 'help' and it 
covers sending to yahoo, not yahoo sending out.  Old server worked, new 
does not.  Of course, yahoo could have changed their policy about that 
time too.  After all, I only started getting the gmail bounces on 
needing an spf a week before the switch and I have very few yahoo 
contacts.  But gmail was clearly them not accepting my emails.




may i recommend that you do your homework *first* before consider plug 
a public reachable MTA to the internet?


I have done a lot of homework.  But I know I don't know even 80% of it.  
Plus a lot is old stuff (like Ident, it seems and dsylexic port rules) 
that don't do anything BAD, but should have been cleared out long ago 
after no longer being needed.

Re: No mail from yahoo or ymail

[Robert Moskowitz]

On 12/05/2014 09:31 AM, Richard wrote:


 Original Message 

Date: Thursday, December 04, 2014 23:19:52 -0500
From: Robert Moskowitz r...@htt-consult.com
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...


I'm seeing a couple of things when I look at your DNS records:

  dig htt-consult.com mx


   ;; ANSWER SECTION:
   htt-consult.com. 43200   IN  MX  30 z9m9z.htt-consult.com.
   htt-consult.com. 43200   IN  MX  40 rigel.htt-consult.com.

   ;; ADDITIONAL SECTION:
   z9m9z.htt-consult.com.   172799  IN  A   208.83.67.147


Your first MX host sometimes resolves to 208.83.67.147, which
doesn't appear to be reachable on port 25. When this resolves to
.180 it is.


Probably 4+ years ago a z9m9z was at .147; for the past 3 years hp7310 
has been using that address!




Your second MX host rigel.htt-consult.com resolves to 208.83.67.188,
which doesn't appear to be reachable on port 25


That is to handle spammers that go to the last MX record, assuming that 
is the real server.  It actually stopped 15% of spam coming into my old 
server.  It is part of the 'nolisting' recommendations. I dropped the 2 
fake pre-MX records, becuase they did not seem to help too much and just 
added delay, while the last bad one did not seem to be causing 
problems.  I am pretty sure I have received yahoo mail with it in 
place.  I can remove it if makes a difference..




Additionally, given the TTL shown on the z9m9z.htt-consult.com.
A-record, did you bring your TTLs down before you made what I assume
was an MX host IPnumber switch? If not, and that 2-day TTL is
indicative of what you generally use, it could be a bit before the
nameservers that various mail servers use will need to requery (and
if they get the .147 address it likely won't do them any good
anyway).


2 days???  This is the SOA I have been using during these changes:

htt-consult.com.IN  SOA onlo.htt-consult.com. 
rgm.htt-consult.com. (

2014120201
2H
20M
2W
2H )

I read this as 2Hours TTL.



To debug this type of thing you need to look at what the outside
world is seeing. Query the DNS so that you see results as seen from
the outside, and then try to telnet (from the outside) to the
resulting ipnumbers.


As I have done.  I use MiFi on my phone and connect another notebook to 
it to look 'in' and did not see this bad IP address that somehow is long 
since hung around.


Got a hunch on that

Re: No mail from yahoo or ymail

[Robert Moskowitz]

On 12/05/2014 10:51 AM, Robert Moskowitz wrote:


On 12/05/2014 09:31 AM, Richard wrote:


 Original Message 

Date: Thursday, December 04, 2014 23:19:52 -0500
From: Robert Moskowitz r...@htt-consult.com
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...


I'm seeing a couple of things when I look at your DNS records:

  dig htt-consult.com mx


   ;; ANSWER SECTION:
   htt-consult.com.43200INMX30 z9m9z.htt-consult.com.
   htt-consult.com.43200INMX40 rigel.htt-consult.com.

   ;; ADDITIONAL SECTION:
   z9m9z.htt-consult.com.172799INA208.83.67.147


Your first MX host sometimes resolves to 208.83.67.147, which
doesn't appear to be reachable on port 25. When this resolves to
.180 it is.


Probably 4+ years ago a z9m9z was at .147; for the past 3 years hp7310 
has been using that address!




Your second MX host rigel.htt-consult.com resolves to 208.83.67.188,
which doesn't appear to be reachable on port 25


That is to handle spammers that go to the last MX record, assuming 
that is the real server.  It actually stopped 15% of spam coming into 
my old server.  It is part of the 'nolisting' recommendations. I 
dropped the 2 fake pre-MX records, becuase they did not seem to help 
too much and just added delay, while the last bad one did not seem to 
be causing problems.  I am pretty sure I have received yahoo mail with 
it in place.  I can remove it if makes a difference..




Additionally, given the TTL shown on the z9m9z.htt-consult.com.
A-record, did you bring your TTLs down before you made what I assume
was an MX host IPnumber switch? If not, and that 2-day TTL is
indicative of what you generally use, it could be a bit before the
nameservers that various mail servers use will need to requery (and
if they get the .147 address it likely won't do them any good
anyway).


2 days???  This is the SOA I have been using during these changes:

htt-consult.com.IN  SOA onlo.htt-consult.com. 
rgm.htt-consult.com. (

2014120201
2H
20M
2W
2H )

I read this as 2Hours TTL.



To debug this type of thing you need to look at what the outside
world is seeing. Query the DNS so that you see results as seen from
the outside, and then try to telnet (from the outside) to the
resulting ipnumbers.


As I have done.  I use MiFi on my phone and connect another notebook 
to it to look 'in' and did not see this bad IP address that somehow is 
long since hung around.


Got a hunch on that


Just checked all of my secondary NS, and they are showing current zone 
information.

Re: No mail from yahoo or ymail

[Robert Moskowitz]

On 12/05/2014 11:03 AM, li...@rhsoft.net wrote:


Am 05.12.2014 um 16:54 schrieb Robert Moskowitz:

Just checked all of my secondary NS, and they are showing current zone
information.


from where?
http://www.intodns.com/ is *mandatory* to start debugging

http://www.intodns.com/htt-consult.com

Error DNS servers responded ERROR: One or more of your nameservers did 
not respond: The ones that did not respond are: 208.83.67.147


It has not been a name server for 4+ years.  It BETTER not be 
responding.  Now why does someone show this.  I will have to go over to 
my Registrar and check there.  I have only been with them for 2 years, 
so I really doubt I will see this showing with them.  But it is probably 
they that will need to fix this upstream.




Missing nameservers reported by your nameservers ERROR: One or more of 
the nameservers listed at the parent servers are not listed as NS 
records at your nameservers. The problem NS records are:
z9m9z.htt-consult.com This is listed as an ERROR because there are 
some cases where nasty problems can occur (if the TTLs vary from the 
NS records at the root servers and the NS records point to your own 
domain, for example).


I also see how I mis-read some error messages.  On a report.  I was 
wondering why it was talking about z9m9z wrt NS.  This is a registrar 
problem.

Re: No mail from yahoo or ymail

[Robert Moskowitz]

On 12/05/2014 11:17 AM, Robert Moskowitz wrote:


On 12/05/2014 11:03 AM, li...@rhsoft.net wrote:


Am 05.12.2014 um 16:54 schrieb Robert Moskowitz:

Just checked all of my secondary NS, and they are showing current zone
information.


from where?
http://www.intodns.com/ is *mandatory* to start debugging

http://www.intodns.com/htt-consult.com

Error DNS servers responded ERROR: One or more of your nameservers 
did not respond: The ones that did not respond are: 208.83.67.147


It has not been a name server for 4+ years.  It BETTER not be 
responding.  Now why does someone show this.  I will have to go over 
to my Registrar and check there.  I have only been with them for 2 
years, so I really doubt I will see this showing with them. But it is 
probably they that will need to fix this upstream.




Missing nameservers reported by your nameservers ERROR: One or more 
of the nameservers listed at the parent servers are not listed as NS 
records at your nameservers. The problem NS records are:
z9m9z.htt-consult.com This is listed as an ERROR because there are 
some cases where nasty problems can occur (if the TTLs vary from the 
NS records at the root servers and the NS records point to your own 
domain, for example).


I also see how I mis-read some error messages.  On a report.  I was 
wondering why it was talking about z9m9z wrt NS.  This is a registrar 
problem.


It was a registrar problem.  All I can guess is when I moved registrars 
almost 2 years ago, the records that got moved were old records from the 
old registrar that had a track record of messing things up for me (one 
of the reasons for the move).  My bad I did not check that what the new 
registrar showed is what I had running at the time.


Thinking back to 4 years ago, and running sendmail I ran a full bind on 
that server as well.  Just found my notes, that set up 7 years ago.  My 
how the Internet has a good memory.


Well 24 hours for the nameserver list to propagate.  Now deal with glue 
records.  I bet that is where the .147 addr is coming from.

Re: No mail from yahoo or ymail

[Robert Moskowitz]

On 12/05/2014 11:24 AM, li...@rhsoft.net wrote:


Am 05.12.2014 um 17:17 schrieb Robert Moskowitz:

On 12/05/2014 11:03 AM, li...@rhsoft.net wrote:

Am 05.12.2014 um 16:54 schrieb Robert Moskowitz:

Just checked all of my secondary NS, and they are showing current zone
information.


from where?
http://www.intodns.com/ is *mandatory* to start debugging

http://www.intodns.com/htt-consult.com

Error DNS servers responded ERROR: One or more of your nameservers did
not respond: The ones that did not respond are: 208.83.67.147


It has not been a name server for 4+ years.  It BETTER not be
responding.  Now why does someone show this.  I will have to go over to
my Registrar and check there.  I have only been with them for 2 years,
so I really doubt I will see this showing with them.  But it is probably
they that will need to fix this upstream.


Missing nameservers reported by your nameservers ERROR: One or more of
the nameservers listed at the parent servers are not listed as NS
records at your nameservers. The problem NS records are:
z9m9z.htt-consult.com This is listed as an ERROR because there are
some cases where nasty problems can occur (if the TTLs vary from the
NS records at the root servers and the NS records point to your own
domain, for example).


I also see how I mis-read some error messages.  On a report.  I was
wondering why it was talking about z9m9z wrt NS.  This is a registrar
problem.


it's *your* responsibility to look at your own public whois and verify 
your configurations published to the world and *not* the registrars


 Domain servers in listed order:
Z9M9Z.HTT-CONSULT.COM
ONLO.HTT-CONSULT.COM
NS2.CLEARRATE.COM
NS1.ICSL.NET
NS1.CLEARRATE.COM


Yep, it is.  And I know I looked at this when I moved registrars.  I 
have deleted the glue record as well.  Now to figure out how to get glue 
records for NS servers in other domains.  The Registrar's tool only 
allows creating glue records within your own domain.  Take this question 
over the the DNS list.

Re: No mail from yahoo or ymail

[Robert Moskowitz]

On 12/05/2014 11:33 AM, Richard wrote:


 Original Message 

Date: Friday, December 05, 2014 10:51:55 -0500
From: Robert Moskowitz r...@htt-consult.com
On 12/05/2014 09:31 AM, Richard wrote:

 Original Message 

Date: Thursday, December 04, 2014 23:19:52 -0500
From: Robert Moskowitz r...@htt-consult.com
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...


I'm seeing a couple of things when I look at your DNS records:

   dig htt-consult.com mx


;; ANSWER SECTION:
htt-consult.com.43200   IN  MX  30 z9m9z.htt-consult.com.
htt-consult.com.43200   IN  MX  40 rigel.htt-consult.com.

;; ADDITIONAL SECTION:
z9m9z.htt-consult.com.  172799  IN  A   208.83.67.147


Your first MX host sometimes resolves to 208.83.67.147, which
doesn't appear to be reachable on port 25. When this resolves to
.180 it is.

Probably 4+ years ago a z9m9z was at .147; for the past 3 years
hp7310 has been using that address!


Your second MX host rigel.htt-consult.com resolves to
208.83.67.188, which doesn't appear to be reachable on port 25

That is to handle spammers that go to the last MX record, assuming
that is the real server.  It actually stopped 15% of spam coming
into my old server.  It is part of the 'nolisting'
recommendations. I dropped the 2 fake pre-MX records, becuase they
did not seem to help too much and just added delay, while the last
bad one did not seem to be causing problems.  I am pretty sure I
have received yahoo mail with it in place.  I can remove it if
makes a difference..


Additionally, given the TTL shown on the z9m9z.htt-consult.com.
A-record, did you bring your TTLs down before you made what I
assume was an MX host IPnumber switch? If not, and that 2-day TTL
is indicative of what you generally use, it could be a bit before
the nameservers that various mail servers use will need to
requery (and if they get the .147 address it likely won't do them
any good anyway).

2 days???  This is the SOA I have been using during these changes:

htt-consult.com.IN  SOA onlo.htt-consult.com.
rgm.htt-consult.com. (
  2014120201
  2H
  20M
  2W
  2H )

I read this as 2Hours TTL.


To debug this type of thing you need to look at what the outside
world is seeing. Query the DNS so that you see results as seen
from the outside, and then try to telnet (from the outside) to the
resulting ipnumbers.

As I have done.  I use MiFi on my phone and connect another
notebook to it to look 'in' and did not see this bad IP address
that somehow is long since hung around.

Got a hunch on that


You may not have been pointing z9m9z at .147 for years, but
there's a nameserver that is showing that. Also you may have the TTL
at 2 hours on the SOA that you are working with, but there's a
nameserver that's returning answers that is showing 2 days:

;; ADDITIONAL SECTION:
z9m9z.htt-consult.com.  172799  IN  A   208.83.67.147

just do the math. What matters is not what you *think* things are
set to, but what is showing to others. [also, if you didn't pull the
TTL down before you made changes it really doesn't matter much what
it is now.]


Oh the change was made back in August in prep for a lot of changes. 
Still have one more to go, and it will get 'worst', as I just found out 
that changing ISPs is no longer just maybe a cost

Re: No mail from yahoo or ymail

[Robert Moskowitz]

On 12/05/2014 11:53 AM, li...@rhsoft.net wrote:


Am 05.12.2014 um 17:35 schrieb Robert Moskowitz:

On 12/05/2014 11:24 AM, li...@rhsoft.net wrote:

it's *your* responsibility to look at your own public whois and verify
your configurations published to the world and *not* the registrars

 Domain servers in listed order:
Z9M9Z.HTT-CONSULT.COM
ONLO.HTT-CONSULT.COM
NS2.CLEARRATE.COM
NS1.ICSL.NET
NS1.CLEARRATE.COM


Yep, it is.  And I know I looked at this when I moved registrars.  I
have deleted the glue record as well.  Now to figure out how to get glue
records for NS servers in other domains.  The Registrar's tool only
allows creating glue records within your own domain.  Take this question
over the the DNS list


no, you just have to read what a GLUE record is


And these wonderful DNS web tools that report no glue records for NS 
servers not under my domain.  I could not see where this is defined.  
And it seems not.  I was again pointed where I was reading, to RFC1034.  
I need glue records for onlo, which I have, but not for ones like ns1.clear


Further, I now see clearly that dig responses I was getting from my MiFi 
connection are incomplete.  No additional information with those 
problems.  Just tested again, and nope, not there.  Won't bother with 
that again.  Might as well just add the @server from regular connection 
to one of the root servers.


But I do thank you for the help, pointing me in the right direction to 
check.  Or rather the more right way to check DNS.  Got notes on this 
for next time.   And there will be a next time.  All that readdressing 
to do.




that's what i meant with doing your homework hours ago because
you ask often the wrong questions (not only on that topic)

http://en.wikipedia.org/wiki/Domain_Name_System#Circular_dependencies_and_glue_records 

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 
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

[Robert Moskowitz]

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]

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: No mail from yahoo or ymail

[Robert Moskowitz]

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...

TLS trusted issuers

[Robert Moskowitz]

Where does Postfix get its list of trusted certificate issuers?  I just 
caught:


Nov 30 16:29:24 z9m9z postfix/smtp[21643]: certificate verification 
failed for ibehy-com.mail.protection.outlook.com[207.46.163.138]:25: 
untrusted issuer /C=IE/O=Baltimore/OU=CyberTrust/CN=Baltimore CyberTrust 
Root


Nov 30 16:30:10 z9m9z postfix/smtp[21643]: 2875E5FA37: 
to=yeh...@ibehy.com, 
relay=ibehy-com.mail.protection.outlook.com[207.46.163.138]:25, 
delay=50, delays=1.7/1.2/2/45, dsn=2.6.0, status=sent (250 2.6.0 
542b126d.5000...@htt-consult.com [InternalId=40325447943556, 
Hostname=BN1PR04MB075.namprd04.prod.outlook.com] Queued mail for delivery)


It sent the message, but did not like CyberTrust as an issuer. 
Considering that that is my daytime employer (Verizon), and I helped 
with the original CyberTrust PKI (well after TruSecure came out of the 
merger of ICSA, Betrusted, and Ubizen), I really should trust their 
signed certs ;)

Re: TLS trusted issuers

[Robert Moskowitz]

On 11/30/2014 04:55 PM, Wietse Venema wrote:

Robert Moskowitz:

Where does Postfix get its list of trusted certificate issuers?

You decide:
http://www.postfix.org/postconf.5.html#tls_append_default_CA


Thanks.  Now I just have to get a CA list onto the server.  As well as 
what format the list is to be in.  Or are they just multiple files in a 
directory.  Got some searching to do.

Re: TLS trusted issuers

[Robert Moskowitz]

On 11/30/2014 06:50 PM, Viktor Dukhovni wrote:

On Sun, Nov 30, 2014 at 06:30:51PM -0500, Robert Moskowitz wrote:


On 11/30/2014 04:55 PM, Wietse Venema wrote:

Robert Moskowitz:

Where does Postfix get its list of trusted certificate issuers?

You decide:
http://www.postfix.org/postconf.5.html#tls_append_default_CA

Thanks.  Now I just have to get a CA list onto the server.  As well as what
format the list is to be in.  Or are they just multiple files in a
directory.  Got some searching to do.

Sufficiently recent versions of Postfix (yours predates at least
2.9) don't bother to pollute the logs with uninteresting verification
failures when delivery proceeds whether the peer chain was trusted
or not:

 http://www.postfix.org/TLS_README.html#client_logging

You don't have to do anything, your protection against active
attacks is not noticeably improved when your logs sometimes happen
to record that the certificate chain was issued by a trusted root
for a few destinations.

Even if you configure a complete (whatever than means) CA-bundle,
opportunistic TLS in Postfix still does not check the certificate
hostname, so you'd know is that the peer certificate was issued by
some trusted CA to some domain or other, possibly completely
unrelated to the target SMTP server.

If you're dead set on going through the motions anyway, you can
put one trusted root CA certificate per file in some directory,
run the OpenSSL c_rehash(1) utility on that directory, and then
configure the directory as your smtp_tls_CApath.  If your master.cf
file does not specify chroot=n for the smtp delivery agent, you'll
to clone the CApath directory into the chroot jail ($queue_directory).

I am not suggesting you do this, but since you asked...

As so often, Viktor, you get right to the 'key' point.  Yes, why 
bother.  Is it any faster if it has a lot of root CA files to check 
against?  Probably not!  And we want opertunistic, in this case, to 
protect against listeners between the MTAs. (but considering all I do in 
secure communications I will not go down the pro/con debate; does not 
belong here).


So leave it alone.  Just another interesting message happening. Nothing 
REALLY interesting, move along...


Ah, for the days of X.400 mail when every mail handler HAD to be 
trusted.  :)

Re: TLS trusted issuers

[Robert Moskowitz]

On 11/30/2014 07:12 PM, Viktor Dukhovni wrote:

On Sun, Nov 30, 2014 at 07:00:15PM -0500, Robert Moskowitz wrote:


I am not suggesting you do this, but since you asked...

As so often, Viktor, you get right to the 'key' point.  Yes, why bother.  Is
it any faster if it has a lot of root CA files to check against?

The performance cost is not an issue.

With CApath, the performance is largely idpendent of the number of
CAs, until you start trusting more than ~65,000 CAs at which point
there is a negligible logarithmic cost due to collisions of the
32-bit hashed issuer DNs.


So leave it alone.  Just another interesting message happening. Nothing
REALLY interesting, move along...

Correct.  In 2.13 (or whatever number we assign to the release
after next), we may add a forensically useful (even if not a
proactive defense) way to employ trusted CAs to try to authenticate
SMTP servers.  You'll know that some connections happened to be
protected, and would need to employ log analysis to look for
anomalies indicative of MiTM attack in order to take advantage of
such forensic evidence.


You would have to 'know' that an MTA does have a trusted cert, and a 
connection claiming to be that MTA is not trusted.  Hmmm, dns offers 
SOME protection here, and of course that takes us to DANE.


My head hurts.  And I have a headcold and a fever anyway, so this is NOT 
the time to try and think this though.

Fixed with spf - Re: google bouncing emails - ipv6 ptr problem?

[Robert Moskowitz]

On 11/22/2014 07:41 AM, Wietse Venema wrote:

A. Schulze:

So instead implementing strange workarounds, one should search, find,
understand and fix the real problem.

Google bounced my mail because of a temp error. I changed nothing
in my DNS or DKIM. It's their bug, not mine.


And with mine, I needed an spf record to make them happy:

htt-consult.com.  IN TXT v=spf1 mx ~all

Now when my wife sends emails to her employer, yby.org, they don't get 
rejected.  The bug is with their error message.  They confound at least 
two problems into one error.

Re: NOT Fixed with spf - Re: google bouncing emails - ipv6 ptr problem?

[Robert Moskowitz]

On 11/24/2014 08:42 AM, Wietse Venema wrote:

Robert Moskowitz:

Google bounced my mail because of a temp error. I changed nothing
in my DNS or DKIM. It's their bug, not mine.

And with mine, I needed an spf record to make them happy:

htt-consult.com.  IN TXT v=spf1 mx ~all

Now when my wife sends emails to her employer, yby.org, they don't get
rejected.  The bug is with their error message.  They confound at least
two problems into one error.

The problem discussed here exists even with good DNS configuration.

Google SOMETIMES rejects a message and minutes later accepts the
SAME message from the SAME source IP address to the SAME server IP
address, with the SAME sender DNS configuration. See logging below.


I understand what you are talking about.  So far, I have not seen it.  
Could be my low traffic.


The spf record at least got them accepting emails again.  The 
enforcement, at least for me, was recent.  I have been messaging google 
for years without spf and with ipv6.  The bounce only started two weeks ago.


So I don't deny/ignore what you have encountered.  So far I have not and 
spf took care of the bounces I was getting.  Indicating at least in my 
case, or some of my cases, the part of the error message applying to me 
was email policy, not ipv6.


Note that I have a /48 allocation from my ISP who has their /40 from 
Verizon.  I was delegated my RDNS that my ISP is secondary for.




Their error message suggests that a) they had a problem looking up
PTR information, and that b) someone made the mistake of translating
a TEMPORARY DNS error into a HARD mail delivery problem.

Wietse

Nov 11 11:55:15 spike postfix/smtp[22958]: 3jcZv4004YzJrPw:
to=censored, relay=aspmx.l.google.com[2607:f8b0:400d:c04::1a]:25,
delay=3.6, delays=0.12/0.01/2.6/0.93, dsn=5.7.1, status=bounced
(host aspmx.l.google.com[2607:f8b0:400d:c04::1a] said: 550-5.7.1
[2604:8d00:189::2] Our system has detected that this message does
not 550-5.7.1 meet IPv6 sending guidelines regarding PTR records
and authentication 550-5.7.1 . Please review 550-5.7.1
https://support.google.com/mail/?p=ipv6_authentication_error for
more 550 5.7.1 information. l17si30149401qaj.81 - gsmtp (in reply
to end of DATA command))

Nov 11 11:58:29 spike postfix/smtp[22980]: 3jcZyr2BpqzJrPw:
to=censored, relay=aspmx.l.google.com[2607:f8b0:400d:c04::1a]:25,
delay=1.4, delays=0.11/0.01/0.19/1.1, dsn=2.0.0, status=sent (250
2.0.0 OK 1415725109 k30si37581932qge.88 - gsmtp)

Re: google bouncing emails - ipv6 ptr problem?

[Robert Moskowitz]

On 11/20/2014 12:50 AM, Robert Schetterer wrote:

Am 20.11.2014 um 01:46 schrieb Wietse Venema:

Robert Moskowitz:

Perhaps this should go to the bind list, but all of my checking shows my
ipv6 ptr record is working.

This started, I think, last week.  I was running an old mailserver and
sent many an email to the cubieboard list.

I had one email bounce last week. Looks like they handle DNS
timeouts badly.  I now send their mail via a transport with
soft_bonce=yes.

Wietse


workaround maybe ,use ipv4 only transport ,for google


How do you set this up?

some sites not accepting self-signed certs

[Robert Moskowitz]

So I have enabled TLS (though I forgot how I did this!) for 
sending/receiving mail.  It ONLY took me a year from when I started 
working on this migration to finally pulling it off.


ANd of course, being on the cheap side, I used self-signed 
certificates.  Well I see some sites, including dovecot.org rejecting 
emails.


Nov 20 10:19:45 z9m9z postfix/lmtp[4040]: 5CF7062110: 
to=dove...@dovecot.org, relay=127.0.0.1[127.0.0.1]:10024, conn_use=12, 
delay=5890, delays=4534/1346/0.01/8.8, dsn=2.0.0, status=sent (250 2.0.0 
Ok, id=04061-01-12, from MTA([127.0.0.1]:10025): 250 2.0.0 Ok: queued as 
8602A600B7)


Nov 20 10:19:46 z9m9z postfix/smtp[4090]: certificate verification 
failed for dovecot.org[137.117.229.219]:25: self-signed certificate



Lovely, lovely.  I CAN understand this.  Afterall, secure communications 
is my day job.  But I don't like it.  Does only accepting well-rooted 
certs matter for server performance?  Are there really DOS attacks 
occuring on sites that accept self-signed certs (this listserver does 
not seem to be using TLS)?


So now I either turn off TLS for MTA-MTA communications, or I find a 
decent CA to get a cert from and I set it up right.


Do others here use self-signed certs in this way?

Re: some sites not accepting self-signed certs

[Robert Moskowitz]

On 11/20/2014 01:52 PM, li...@rhsoft.net wrote:


Am 20.11.2014 um 19:47 schrieb Robert Moskowitz:

So I have enabled TLS (though I forgot how I did this!) for
sending/receiving mail.  It ONLY took me a year from when I started
working on this migration to finally pulling it off.

ANd of course, being on the cheap side, I used self-signed
certificates.  Well I see some sites, including dovecot.org rejecting
emails.

Nov 20 10:19:45 z9m9z postfix/lmtp[4040]: 5CF7062110:
to=dove...@dovecot.org, relay=127.0.0.1[127.0.0.1]:10024, conn_use=12,
delay=5890, delays=4534/1346/0.01/8.8, dsn=2.0.0, status=sent (250 2.0.0
Ok, id=04061-01-12, from MTA([127.0.0.1]:10025): 250 2.0.0 Ok: queued as
8602A600B7)

Nov 20 10:19:46 z9m9z postfix/smtp[4090]: certificate verification
failed for dovecot.org[137.117.229.219]:25: self-signed certificate

Lovely, lovely.  I CAN understand this.  Afterall, secure communications
is my day job.  But I don't like it.  Does only accepting well-rooted
certs matter for server performance?  Are there really DOS attacks
occuring on sites that accept self-signed certs (this listserver does
not seem to be using TLS)?

So now I either turn off TLS for MTA-MTA communications, or I find a
decent CA to get a cert from and I set it up right.

Do others here use self-signed certs in this way?


what are you talking about?
that above is most likely just a warning for the record

you missed to provide *full logs* for that transaction as well as 
postconf -n output - postfix don't reject self signed certificates 
until somebody decides to configure it that way


I jsut determined that I have not received any messages from dovecot.org 
to my new email server.  I normally get 10 - 20 emails a day from that 
list.  I sent a message to the list today to ask about more detailed 
reporting to logwatch and here are the maillog messages you asked for:


Nov 20 10:19:37 z9m9z amavis[4061]: (04061-01-12) LMTP::10024 
/var/spool/amavisd/tmp/amavis-20141120T101739-04061: 
r...@htt-consult.com - dove...@dovecot.org SIZE=4010 Received: from 
z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com 
[127.0.0.1]) (amavisd-new, port 10024) with LMTP for 
dove...@dovecot.org; Thu, 20 Nov 2014 10:19:37 -0500 (EST)


Nov 20 10:19:37 z9m9z amavis[4061]: (04061-01-12) Checking: mvxDjgVVZpL6 
MYNETS [208.83.67.156] r...@htt-consult.com - dove...@dovecot.org


Nov 20 10:19:45 z9m9z amavis[4061]: (04061-01-12) FWD via SMTP: 
r...@htt-consult.com - dove...@dovecot.org,BODY=7BIT 250 2.0.0 Ok, 
id=04061-01-12, from MTA([127.0.0.1]:10025): 250 2.0.0 Ok: queued as 
8602A600B7


Nov 20 10:19:45 z9m9z amavis[4061]: (04061-01-12) Passed CLEAN, MYNETS 
LOCAL [208.83.67.156] [208.83.67.156] r...@htt-consult.com - 
dove...@dovecot.org, Message-ID: 546def8a.1080...@htt-consult.com, 
mail_id: mvxDjgVVZpL6, Hits: -2.91, size: 4010, queued_as: 8602A600B7, 
8739 ms


Nov 20 10:19:45 z9m9z postfix/lmtp[4040]: 5CF7062110: 
to=dove...@dovecot.org, relay=127.0.0.1[127.0.0.1]:10024, conn_use=12, 
delay=5890, delays=4534/1346/0.01/8.8, dsn=2.0.0, status=sent (250 2.0.0 
Ok, id=04061-01-12, from MTA([127.0.0.1]:10025): 250 2.0.0 Ok: queued as 
8602A600B7)


Nov 20 10:19:46 z9m9z postfix/smtp[4090]: certificate verification 
failed for dovecot.org[137.117.229.219]:25: self-signed certificate


Nov 20 10:19:47 z9m9z postfix/smtp[4090]: 8602A600B7: 
to=dove...@dovecot.org, relay=dovecot.org[137.117.229.219]:25, 
delay=2.2, delays=0.09/0.03/1.5/0.52, dsn=2.0.0, status=sent (250 2.0.0 
Ok: queued as B57F32347A)


Sure looks like dovecot.org rejected my MTA connection.  I doubt when 
the requeued message tries again it will go through.


So I decided to look to see if I can see anything coming from 
dovecot.org, and maybe them dropping the connection when they get my 
self-signed cert.  But nothing for incoming connections from 
dovecot.org.  Would have to increase some sort of logging activity to 
discover that.


Of course this means if dovecot.org won't take emails from my MTA, and 
it looks like won't send any either, there are probably other sites, 
that I can't figure out are also not sending emails now. Without 
increasing logging to discover failed connections, and would they even 
tell me that they did not like my cert?

Re: some sites not accepting self-signed certs

[Robert Moskowitz]

On 11/20/2014 01:52 PM, li...@rhsoft.net wrote:


Am 20.11.2014 um 19:47 schrieb Robert Moskowitz:

So I have enabled TLS (though I forgot how I did this!) for
sending/receiving mail.  It ONLY took me a year from when I started
working on this migration to finally pulling it off.

ANd of course, being on the cheap side, I used self-signed
certificates.  Well I see some sites, including dovecot.org rejecting
emails.

Nov 20 10:19:45 z9m9z postfix/lmtp[4040]: 5CF7062110:
to=dove...@dovecot.org, relay=127.0.0.1[127.0.0.1]:10024, conn_use=12,
delay=5890, delays=4534/1346/0.01/8.8, dsn=2.0.0, status=sent (250 2.0.0
Ok, id=04061-01-12, from MTA([127.0.0.1]:10025): 250 2.0.0 Ok: queued as
8602A600B7)

Nov 20 10:19:46 z9m9z postfix/smtp[4090]: certificate verification
failed for dovecot.org[137.117.229.219]:25: self-signed certificate

Lovely, lovely.  I CAN understand this.  Afterall, secure communications
is my day job.  But I don't like it.  Does only accepting well-rooted
certs matter for server performance?  Are there really DOS attacks
occuring on sites that accept self-signed certs (this listserver does
not seem to be using TLS)?

So now I either turn off TLS for MTA-MTA communications, or I find a
decent CA to get a cert from and I set it up right.

Do others here use self-signed certs in this way?


what are you talking about?
that above is most likely just a warning for the record

you missed to provide *full logs* for that transaction as well as 
postconf -n output - postfix don't reject self signed certificates 
until somebody decides to configure it that way


Oh, and here are my tls main.cf setup commands from my main.cf config 
script:


# tls config
postconf -e 'smtp_use_tls = yes'
postconf -e 'smtp_tls_note_starttls_offer = yes'
postconf -e 'smtp_tls_session_cache_database = 
btree:$data_directory/smtp_tls_session_cache'

postconf -e 'smtpd_use_tls = yes'
postconf -e 'smtpd_tls_loglevel = 1'
postconf -e 'smtpd_tls_received_header = yes'
postconf -e 'smtpd_tls_security_level = may'
postconf -e 'smtpd_tls_session_cache_database = 
btree:/var/lib/postfix/smtpd_scache'

# Change mail.example.com.* to your host name
postconf -e 'smtpd_tls_key_file = 
/etc/pki/tls/private/z9m9z.htt-consult.com.key'
postconf -e 'smtpd_tls_cert_file = 
/etc/pki/tls/certs/z9m9z.htt-consult.com.crt'

Re: some sites not accepting self-signed certs

[Robert Moskowitz]

On 11/20/2014 01:56 PM, Viktor Dukhovni wrote:

On Thu, Nov 20, 2014 at 01:47:20PM -0500, Robert Moskowitz wrote:


And of course, being on the cheap side, I used self-signed certificates.
Well I see some sites, including dovecot.org rejecting emails.

Nov 20 10:19:45 z9m9z postfix/lmtp[4040]: 5CF7062110:
to=dove...@dovecot.org, relay=127.0.0.1[127.0.0.1]:10024, conn_use=12,
delay=5890, delays=4534/1346/0.01/8.8, dsn=2.0.0, status=sent (250 2.0.0 Ok,
id=04061-01-12, from MTA([127.0.0.1]:10025): 250 2.0.0 Ok: queued as
8602A600B7)

Nov 20 10:19:46 z9m9z postfix/smtp[4090]: certificate verification failed
for dovecot.org[137.117.229.219]:25: self-signed certificate

This is email you're sending, but certs are inspected by sending
not receiving systems.  Your self signed certificate has no bearing
on delivery of outbound email.


I have spent too many years on PKI, and that definitely colors my view.  
You are saying that this is only server cert, not client cert in the TLS 
handshake.  OK.  I can accept that.



You're showing an irrelevant log entry for email re-injection into
amavisd-new for scanning.  And no evidence than anyone is rejecting
your mail,


I will accept that I did misread who was rejecting what.  Bad for me to 
assume that my MTA cert was also being used as a client cert.  By your 
explanation, dovecot.org is ALSO using a self-signed cert and my MTA is 
the one rejecting their cert. This is the only maillog message for 
self-signed cert failed.  But all that means is that they are the only 
MTA I have sent mail to that is using a self-signed cert.



In other words, you're so confused, that you're babbling nonsense,
but it seems to make sense to you.  You need to forget everything
you think you understood and start again from scratch.


The confusion comes in as to what the MTA cert is used for.  I now see 
it is used only for the TLS server cert.  Fine.


Though now I have to figure out IF they received my message and why I am 
not getting any mail from them.





Lovely, lovely.  I CAN understand this.  Afterall, secure communications is
my day job.  But I don't like it.

Well the premise is false, so there is nothing to not like.


So now I either turn off TLS for MTA-MTA communications, or I find
a decent CA to get a cert from and I set it up right.

No need.


Do others here use self-signed certs?

Definitely.

Re: some sites not accepting self-signed certs

[Robert Moskowitz]

On 11/20/2014 02:14 PM, Wietse Venema wrote:

Robert Moskowitz:

Nov 20 10:19:47 z9m9z postfix/smtp[4090]: 8602A600B7:
to=dove...@dovecot.org, relay=dovecot.org[137.117.229.219]:25,
delay=2.2, delays=0.09/0.03/1.5/0.52, dsn=2.0.0, status=sent (250 2.0.0
Ok: queued as B57F32347A)

Sure looks like dovecot.org rejected my MTA connection.  I doubt when
the requeued message tries again it will go through.

Huh? Your email was accepted and queued with an ID of B57F32347A.

Wietse


Perhaps the problem is dovecot.org.

via http://dovecot.org/list/dovecot/2014-November/date.html

There HAS been no mail posted there since before my server switch. What 
a coincidence.  But my mail message is not showing either in the 
archive.  So if they got it it is their problem, and with all the little 
nits I have missed (like group permissions on amavis directories for 
clam), that I jumped the wrong way.


So I apologize.  You are all here a great help for me.

Back to figuring out if I am going to limit google to IPv4 only or 
figure out what they want for IPv6.  I SHOULD know enough people at 
google to really get to the source of this.  I really would rather be 
using IPv6 over IPv4.


thanks all.

Dovecot list fixed - Re: some sites not accepting self-signed certs

[Robert Moskowitz]

the problem WAS the dovecot list.  I finally reached the list manager 
and he gave it a kick.


I mean the problem HAS to be MY config, nothing goes wrong out there on 
the net...


thanks again.

On 11/20/2014 02:14 PM, Wietse Venema wrote:

Robert Moskowitz:

Nov 20 10:19:47 z9m9z postfix/smtp[4090]: 8602A600B7:
to=dove...@dovecot.org, relay=dovecot.org[137.117.229.219]:25,
delay=2.2, delays=0.09/0.03/1.5/0.52, dsn=2.0.0, status=sent (250 2.0.0
Ok: queued as B57F32347A)

Sure looks like dovecot.org rejected my MTA connection.  I doubt when
the requeued message tries again it will go through.

Huh? Your email was accepted and queued with an ID of B57F32347A.

Wietse

google bouncing emails - ipv6 ptr problem?

[Robert Moskowitz]

Perhaps this should go to the bind list, but all of my checking shows my 
ipv6 ptr record is working.


This started, I think, last week.  I was running an old mailserver and 
sent many an email to the cubieboard list.


Just today I finally upgraded my mailserver, but still get the bounce.  
My current system is running Redsleeve 6 (Centos 6 for ARM), and 
postfix-2.6.6-6


The bounce from google says:

   The mail system

cubiebo...@googlegroups.com: host
gmr-smtp-in.l.google.com[2607:f8b0:4001:c08::e] said: 550-5.7.1
[2607:f4b8:3:3:67:15ff:fe00:180] Our system has detected that this
550-5.7.1 message does not meet IPv6 sending guidelines regarding PTR
records 550-5.7.1 and authentication. Please review 550-5.7.1
https://support.google.com/mail/?p=ipv6_authentication_error  for more 550
5.7.1 information. f9si145249igt.0 - gsmtp (in reply to end of DATA
command)


Reporting-MTA: dns; z9m9z.htt-consult.com
X-Postfix-Queue-ID: 6FC565FA07
X-Postfix-Sender: rfc822;r...@htt-consult.com
Arrival-Date: Wed, 19 Nov 2014 08:48:16 -0500 (EST)

Final-Recipient: rfc822;cubiebo...@googlegroups.com
Original-Recipient:rfc822;cubiebo...@googlegroups.com
Action: failed
Status: 5.7.1
Remote-MTA: dns; gmr-smtp-in.l.google.com
Diagnostic-Code: smtp; 550-5.7.1 [2607:f4b8:3:3:67:15ff:fe00:180] Our system
has detected that this 550-5.7.1 message does not meet IPv6 sending
guidelines regarding PTR records 550-5.7.1 and authentication. Please
review 550-5.7.1
https://support.google.com/mail/?p=ipv6_authentication_error  for more 550
5.7.1 information. f9si145249igt.0 - gsmtp




I checked via my Verizon wireless MiFi connection and that IPv6 address 
ptr does point to z9m9z.htt-consult.com  I have gone to the listed web 
page, and believe my ipv6 dns is correct.  I have not implemented spf or 
dkim.  I am now getting TLS connections between my MTA and others.


Could it be some other problem with my postfix setup?  Or DNS?

Re: google bouncing emails - ipv6 ptr problem?

[Robert Moskowitz]

This is kind of what I was thinking was the case...

On 11/19/2014 07:28 PM, Mark Martinec wrote:

Robert Moskowitz wrote:

Perhaps this should go to the bind list, but all of my checking shows
my ipv6 ptr record is working.

This started, I think, last week.  I was running an old mailserver and
sent many an email to the cubieboard list.

Just today I finally upgraded my mailserver, but still get the bounce.
 My current system is running Redsleeve 6 (Centos 6 for ARM), and
postfix-2.6.6-6

The bounce from google says:

   The mail system

cubiebo...@googlegroups.com: host
gmr-smtp-in.l.google.com[2607:f8b0:4001:c08::e] said: 550-5.7.1
[2607:f4b8:3:3:67:15ff:fe00:180] Our system has detected that this
550-5.7.1 message does not meet IPv6 sending guidelines regarding 
PTR

records 550-5.7.1 and authentication. Please review 550-5.7.1
https://support.google.com/mail/?p=ipv6_authentication_error for more 
550

5.7.1 information. f9si145249igt.0 - gsmtp (in reply to end of DATA
command)


Note the '...and authentication' in that message!

Read that web document again, note the 'Additional guidelines for IPv6'
and the second bullet there:

  . The sending domain should pass either SPF check or DKIM check.
Otherwise, mail might be marked as spam.


But until I confirmed from others that DNS looked ok.  Also until today, 
I could not implement DKIM, if I wanted to.







I checked via my Verizon wireless MiFi connection and that IPv6
address ptr does point to z9m9z.htt-consult.com  I have gone to the
listed web page, and believe my ipv6 dns is correct.


Looks alright, although DNS checkers have some complaints
regarding your domain:

  http://www.webwiz.co.uk/domain-tools/


There ARE some reverse look up issues, but I am doing it the way you 
need to if your reverse lookup is delegated from a larger block.  I will 
need to look further into this.



  http://www.intodns.com/
  http://www.dnsqueries.com/en/



I have not implemented spf or dkim.


There you go!
Consider also publishing a DMARC record, not necessarily restrictive.


Will have to read up on DMARC records.  Hopefully they are not as bad as 
spf are.

Re: google bouncing emails - ipv6 ptr problem?

[Robert Moskowitz]

On 11/19/2014 07:46 PM, Wietse Venema wrote:

Robert Moskowitz:

Perhaps this should go to the bind list, but all of my checking shows my
ipv6 ptr record is working.

This started, I think, last week.  I was running an old mailserver and
sent many an email to the cubieboard list.

I had one email bounce last week. Looks like they handle DNS
timeouts badly.  I now send their mail via a transport with
soft_bonce=yes.


Can you point me to more for me to learn about soft_bounce?  And how you 
have a transport specific to google?


Thanks for the continued education.  Finally I am running my own config 
that I had to build myself (with lots of help!), so now I need to 
continue along this path.

Re: Does this IP have reverse DNS?

[Robert Moskowitz]

On 03/04/2013 01:06 PM, Blake Hudson wrote:

Just hoping to get a consensus  on this. Postfix is stating that a

 host (in fact several hosts from the same ISP) does not have rDNS,
 because our DNS (Bind 9.8) returns SERVFAIL when looking up a PTR
 record for it. The IP in question is 63.171.0.212. From my
 perspective, this IP does not have a PTR record and as such does not
 have proper rDNS. Other tools (including older versions of bind)
 might say otherwise; What do you say?

host 63.171.0.212
212.0.171.63.in-addr.arpa is an alias for 
63.171.0.212.cust.lkq.sprintlink.net.

63.171.0.212.cust.lkq.sprintlink.net domain name pointer mail1.lkqcorp.com.

Re: Running namecache service on postfix server?

[Robert Moskowitz]

On 02/27/2013 01:21 AM, Viktor Dukhovni wrote:

On Tue, Feb 26, 2013 at 08:57:51PM -0500, b...@bitrate.net wrote:


When Postfix support for DANE (RFC 6698) is introduced, there will
be a requirement to operate a local nameserver that is DNSSEC aware
on any machine that wants to take advantage of peer certificate details
published via DNSSEC to scalably deliver verified TLS email to many
sites without the overhead of local per-site configuration.

Why must the nameserver be local?

Very easy. If the server is *not* local, you should not trust the
AD-bit in its responses without authenticating the nameserver via
something like TSIG.

I am not going to bloat Postfix with TSIG support, this would be
really silly, when a local cache can take care of that. A fortiori
I am not going to bloat Postfix with its own RRSIG-validing DNSSEC
support.  Therefore, Postfix support for DANE will be sensibly
predicated on a *local* DNSSEC verifying cache.

Unless we add code to check that the resolv.conf in fact only
contains local servers (I am disinclined to do that also), you will
be able to break the warranty and trust the AD-bit from non-local
nameservers by telling Postfix to enable DANE even with a resolv.conf
that points to remote servers. If you do that, you only have yourself
to blame when lack of TSIG, ... makes it possible to MITM your
server's ostensibly secure email deliveries.


Ah, thought there was a MITM lurking around the corner if DNS server not 
local. Thank you for the details.



All, I can say (and will say in the documentation) is that you've
been warned. Since the fields of _res other than _res.options
are not generally documented, there is no reasonable way to perform
a run-time check that the configured nameservers consist of just
127.0.0.1 and/or ::1.


I had to add listen on the server's IP addresses.  Some services require 
that.



So the plan is to document the warning clearly
in all the relevant documents, and leave the rest to the administrator's
ability to restrain himself from folly.

Perhaps postfix check could generate a warning if DANE is enabled
and non-local nameservers are found in /etc/resolv.conf (or and/or
its chroot-jail version).


My main DNS server is no longer chrooted, as selinux is claimed to be 
better protection.  And people better at OS security than I have vetted it.


But with this, I realize that I have had to turn off selinux on my mail 
server.  Or rather I have not found selinux assistance for all the 
services needed on a mail server that 'does it all'.  Therefore got to 
add chroot for bind.

Re: Running namecache service on postfix server?

[Robert Moskowitz]

On 02/27/2013 06:58 AM, Wietse Venema wrote:

Viktor Dukhovni:

Perhaps postfix check could generate a warning if DANE is enabled
and non-local nameservers are found in /etc/resolv.conf (or and/or
its chroot-jail version).

I think it would be entirely reasonable to share a DNS cache among
multiple systems within the same trusted perimeter. One DNS server
per host in a farm of mail servers may not be practical.


In such a case I would run IPsec between them with a policy for only DNS 
traffic through the tunnel. ESP encapsulation is rather cheap and 
assures you the traffic is going where you want it.


Or if you have very good VLAN control, you could run 802.1AE, but the 
app space cannot tell (typically) if MACsec is working.

Re: Running namecache service on postfix server?

[Robert Moskowitz]

On 02/27/2013 09:25 AM, DTNX Postmaster wrote:

On Feb 27, 2013, at 12:58, Wietse Venema wie...@porcupine.org wrote:


Viktor Dukhovni:

Perhaps postfix check could generate a warning if DANE is enabled
and non-local nameservers are found in /etc/resolv.conf (or and/or
its chroot-jail version).

I think it would be entirely reasonable to share a DNS cache among
multiple systems within the same trusted perimeter. One DNS server
per host in a farm of mail servers may not be practical.

A local cache on each, forwarding to two or three resolvers that are
nearby? Local for DNSSEC verification, nearby cache for performance
reasons? Am I missing something that would make that impractical?


Lots of cat skinners out here.

Re: Running namecache service on postfix server?

[Robert Moskowitz]

On 02/27/2013 10:20 AM, Wietse Venema wrote:

DTNX Postmaster:

On Feb 27, 2013, at 12:58, Wietse Venema wie...@porcupine.org wrote:


Viktor Dukhovni:

Perhaps postfix check could generate a warning if DANE is enabled
and non-local nameservers are found in /etc/resolv.conf (or and/or
its chroot-jail version).

I think it would be entirely reasonable to share a DNS cache among
multiple systems within the same trusted perimeter. One DNS server
per host in a farm of mail servers may not be practical.

A local cache on each, forwarding to two or three resolvers that are
nearby? Local for DNSSEC verification, nearby cache for performance
reasons? Am I missing something that would make that impractical?

I think it would be helpful to give examples of how secure DNS
caches can be shared, instead of outright banning this. On non-trivial
deployments, DNS and MAIL are managed by different people.


True, but we are talking about a namecaching server here, not your 
standard fare for DNS support people. Or rather they are old hands at 
deploying caching servers where appropriate and could well supply 
standard templates for them.


RHEL/Centos bind installs as a caching server, requiring very little in 
edits, though as I pointed out in an earlier message I need to add 
chroot since I have selinux off on the mail server (I don't think it was 
postfix, but rather dovecot that forced this). Also I think if I change 
my DNS address in ifcfg-eth0 to 127.0.0.1 and ::1 I can stop bind 
listening on the local addresses so even less added to named.conf.


But to share a single DNS among a number of mail servers, say in a mail 
farm that probably has lots of other types of servers running with 
questionable content, I would want secure tunnels from the mail server 
to the DNS server and that no longer is a non-trivial exercise. Now you 
can always use my HIP protocol instead of IKEv2 for keying ESP, but 
people doing this may want distro provided tunneling.


How much resources does a local caching server demand? I would think it 
is mostly memory for the cache. You may have to throw a couple more Gb 
at loaded server.

Re: Running namecache service on postfix server?

[Robert Moskowitz]

On 02/27/2013 11:10 AM, Viktor Dukhovni wrote:
I think we've beaten this thread to death, I'm done for now. 


And I thank you for all you have said.

Re: Running namecache service on postfix server?

[Robert Moskowitz]

On 02/27/2013 10:43 AM, Viktor Dukhovni wrote:

On Wed, Feb 27, 2013 at 10:20:50AM -0500, Wietse Venema wrote:


I think it would be entirely reasonable to share a DNS cache among
multiple systems within the same trusted perimeter. One DNS server
per host in a farm of mail servers may not be practical.

A local cache on each, forwarding to two or three resolvers that are
nearby? Local for DNSSEC verification, nearby cache for performance
reasons? Am I missing something that would make that impractical?

I think it would be helpful to give examples of how secure DNS
caches can be shared, instead of outright banning this. On non-trivial
deployments, DNS and MAIL are managed by different people.

This was the intent of my original example, I guess I did not draw
sufficient attention to the:

forward-zone:
name: .
forward-addr: 192.0.2.1

stanza at the bottom of the unbound.conf example. We'll need to
provide a similar configuration example for BIND, and explain the
rationale for both, so other local nameservers could also be
supported by an MTA administrator who understands the requirements.


On Centos 6.3 (bind 9.8.2 with security patches) I did:

yum install bind bind-chroot

In /etc/sysconfig/network-scripts/ifcfg-eth0 set:

DNS1=127.0.0.1
DNS2=::1

ifdown eth0; ifup eth0

Add to /var/named/chroot/etc/named.conf options section:

forward only;
forwarders {
'IPv4 addr of forwarded server';
'IPv6 addr of forwarded server';
'etc.';
};


service bind start
chkconfig bind on

You CAN use 'forward first' and then if your forward server is 
unreachable, your caching server will go out on the net to the '.' 
servers and walk down from there. Look at 'first' as opportunistic local 
forwarding and 'only' as forced local forwarding.

Re: Running namecache service on postfix server?

[Robert Moskowitz]

On 02/27/2013 11:47 AM, Reindl Harald wrote:


Am 27.02.2013 17:42, schrieb Robert Moskowitz:

On Centos 6.3 (bind 9.8.2 with security patches) I did:

yum install bind bind-chroot

In /etc/sysconfig/network-scripts/ifcfg-eth0 set:

DNS1=127.0.0.1
DNS2=::1

ifdown eth0; ifup eth0

Add to /var/named/chroot/etc/named.conf options section:

forward only;
forwarders {
'IPv4 addr of forwarded server';
'IPv6 addr of forwarded server';
'etc.';
};

hopefully to your own TRSUTABLE forwarders and not
to ISP resolvers which all of their mangeling and
the problems if you use spamhaus.org and such blacklists
that you get blocked


Yes, you ONLY forward to servers where there is agreement that you MAY 
use them as forwarders.  This is typically your own main DNS servers.  
Otherwise, it runs 'out-of-the-box' as a caching server using the 
regular '.' hints to find things.


Another tidbit is you should firewall access to port 53.  Your caching 
server is only for you.  It is listening only on localhost, but why open 
up a port not needed.

Re: Running namecache service on postfix server?

[Robert Moskowitz]

On 02/27/2013 12:26 PM, DTNX Postmaster wrote:

On Feb 27, 2013, at 18:05, Robert Moskowitz r...@htt-consult.com wrote:


Another tidbit is you should firewall access to port 53.  Your caching server 
is only for you.  It is listening only on localhost, but why open up a port not 
needed.

Review the examples given again, please. Why would you need to firewall
a local nameserver that ONLY listens on the localhost interface?


I would hope you are running local firewall, and only opening what is 
needed.  Just pointing out that there is no need to open port 53 as it 
is only used local.


Also about chroot.  Only needed if you disable selinux.

Server found while in construction - beware

[Robert Moskowitz]

Lesson here about how open you make a new server while under 
construction.  Fortunately for me, my first step before starting postfix 
was to apply my 'recipe' of postconf commands?  Anyway the system is 
publicly addressed, but on a different subnet than the production box it 
will replace.  I am running this way, as this time if all goes right 
(and this is my 5th build test), I drain the old box, change the 
addresses on this new one and swap them out.


Public DNS for this is its IPaddr.domain so it shows how the robots look 
for any working address with port 25 available:


Feb 27 03:57:23 klovia postfix/smtpd[7677]: connect from 
36-231-85-78.dynamic-ip.hinet.net[36.231.85.78]
Feb 27 03:57:24 klovia postfix/smtpd[7677]: NOQUEUE: reject: RCPT from 
36-231-85-78.dynamic-ip.hinet.net[36.231.85.78]: 554 5.7.1 
1...@k888.tw: Relay access denied; from=a...@hotmail.com 
to=1...@k888.tw proto=SMTP helo=208.83.67.180
Feb 27 03:57:24 klovia postfix/smtpd[7677]: lost connection after RCPT 
from 36-231-85-78.dynamic-ip.hinet.net[36.231.85.78]
Feb 27 03:57:24 klovia postfix/smtpd[7677]: disconnect from 
36-231-85-78.dynamic-ip.hinet.net[36.231.85.78]
Feb 27 04:00:44 klovia postfix/anvil[7679]: statistics: max connection 
rate 1/60s for (smtp:36.231.85.78) at Feb 27 03:57:23
Feb 27 04:00:44 klovia postfix/anvil[7679]: statistics: max connection 
count 1 for (smtp:36.231.85.78) at Feb 27 03:57:23
Feb 27 04:00:44 klovia postfix/anvil[7679]: statistics: max cache size 1 
at Feb 27 03:57:23
Feb 27 08:11:07 klovia postfix/smtpd[8254]: connect from 
36-231-85-78.dynamic-ip.hinet.net[36.231.85.78]
Feb 27 08:11:08 klovia postfix/smtpd[8254]: NOQUEUE: reject: RCPT from 
36-231-85-78.dynamic-ip.hinet.net[36.231.85.78]: 554 5.7.1 
1...@k888.tw: Relay access denied; from=a...@hotmail.com 
to=1...@k888.tw proto=SMTP helo=208.83.67.180
Feb 27 08:11:08 klovia postfix/smtpd[8254]: lost connection after RCPT 
from 36-231-85-78.dynamic-ip.hinet.net[36.231.85.78]
Feb 27 08:11:08 klovia postfix/smtpd[8254]: disconnect from 
36-231-85-78.dynamic-ip.hinet.net[36.231.85.78]
Feb 27 08:14:28 klovia postfix/anvil[8256]: statistics: max connection 
rate 1/60s for (smtp:36.231.85.78) at Feb 27 08:11:07
Feb 27 08:14:28 klovia postfix/anvil[8256]: statistics: max connection 
count 1 for (smtp:36.231.85.78) at Feb 27 08:11:07
Feb 27 08:14:28 klovia postfix/anvil[8256]: statistics: max cache size 1 
at Feb 27 08:11:07
Feb 27 12:26:46 klovia postfix/smtpd[9705]: connect from 
36-231-85-78.dynamic-ip.hinet.net[36.231.85.78]
Feb 27 12:26:47 klovia postfix/smtpd[9705]: NOQUEUE: reject: RCPT from 
36-231-85-78.dynamic-ip.hinet.net[36.231.85.78]: 554 5.7.1 
1...@k888.tw: Relay access denied; from=a...@hotmail.com 
to=1...@k888.tw proto=SMTP helo=208.83.67.180
Feb 27 12:26:47 klovia postfix/smtpd[9705]: lost connection after RCPT 
from 36-231-85-78.dynamic-ip.hinet.net[36.231.85.78]
Feb 27 12:26:47 klovia postfix/smtpd[9705]: disconnect from 
36-231-85-78.dynamic-ip.hinet.net[36.231.85.78]
Feb 27 12:30:07 klovia postfix/anvil[9707]: statistics: max connection 
rate 1/60s for (smtp:36.231.85.78) at Feb 27 12:26:46
Feb 27 12:30:07 klovia postfix/anvil[9707]: statistics: max connection 
count 1 for (smtp:36.231.85.78) at Feb 27 12:26:46
Feb 27 12:30:07 klovia postfix/anvil[9707]: statistics: max cache size 1 
at Feb 27 12:26:46

Running namecache service on postfix server?

[Robert Moskowitz]

I have recently updated my DNS server and am observing the traffic from 
my mail server to constantly query for names.  Some of these names are 
frequent requests, for example: zen.spamhaus.org.  So I was thinking 
that I could benefit from running a namecaching setup on my mail server 
platform.  This would cut down on traffic and time on my mail server.


Is this a practice that is common?  Are there any downsizes to doing this?

Re: Running namecache service on postfix server?

[Robert Moskowitz]

On 02/26/2013 10:10 AM, Reindl Harald wrote:


Am 26.02.2013 15:58, schrieb Robert Moskowitz:

I have recently updated my DNS server and am observing the traffic from my mail 
server to constantly query for
names.  Some of these names are frequent requests, for example: 
zen.spamhaus.org.  So I was thinking that I could
benefit from running a namecaching setup on my mail server platform.  This 
would cut down on traffic and time on my
mail server.

Is this a practice that is common?  Are there any downsizes to doing this?

virtually anybody with a large mail/connection traffic has a chaching
nameserver on his mailservers running, it is common practice


thanks.  One more piece learned.

Re: Running namecache service on postfix server?

[Robert Moskowitz]

On 02/26/2013 08:57 PM, b...@bitrate.net wrote:

On Feb 26, 2013, at 11.51, Viktor Dukhovni postfix-us...@dukhovni.org wrote:


On Tue, Feb 26, 2013 at 09:58:54AM -0500, Robert Moskowitz wrote:


I have recently updated my DNS server and am observing the traffic
from my mail server to constantly query for names.  Some of these
names are frequent requests, for example: zen.spamhaus.org.  So I
was thinking that I could benefit from running a namecaching setup
on my mail server platform.  This would cut down on traffic and time
on my mail server.

Is this a practice that is common?  Are there any downsizes to doing this?

When Postfix support for DANE (RFC 6698) is introduced, there will
be a requirement to operate a local nameserver that is DNSSEC aware
on any machine that wants to take advantage of peer certificate details
published via DNSSEC to scalably deliver verified TLS email to many
sites without the overhead of local per-site configuration.

why must the nameserver be local?  i gather the point is to be able to trust 
the dns responses, which of course goes without saying - but there are methods 
for accomplishing this in scenarios with a non local nameserver, aren't there?  
i think rfc 6698 speaks to this briefly?


I don't think there is a MUST there in the IETF tradition.  More of a 
SHOULD; I think it is a matter of performance, and perhaps security (I 
would have to net it out; definitely less 'room' for a MITM).  I suspect 
people with experience in this area (mine is elsewhere in the IETF and 
IEEE 802) can well list the advantages of 'co-location'.

content_filter and firewall rules

[Robert Moskowitz]

It seems from my limited testing that with the content_filter option of:

content_filter=amavisfeed:[127.0.0.1]:10024

I don't need an iptables rule for port 10024, as there is no firewall 
blocking of localhost connection to ports.


As long as I don't do something stupid like:

content_filter=amavisfeed:myserver.com:10024

which would route the connection through the server's IP address rather 
than localhost.


Same with the 10025 injection back into postfix from the content filter.

Just no reason to open up 10024  10025.

Have I got this correct?

Testing out SMTPS

[Robert Moskowitz]

I am into final tuning of my mail server, and I greatly appreciate all 
the help I have received from the many lists I have had to go to for 
help.  I am now at actual external testing, starting out with some free 
mail test servers.  Right now I am trying out:


http://www.emailsecuritygrader.com

And from there I became aware that I probably don't have SMTPS (port 
465) configured properly.  Actually at first I did not even have it set 
up!  So I reread the readme:


http://www.postfix.org/TLS_README.html

And add:

/etc/postfix/main.cf
smtpd_tls_security_level = may
smtpd_tls_session_cache_database = btree:/var/lib/postfix/smtpd_scache

/etc/postfix/master.cf:
smtpsinet  n   -   n   -   -   smtpd
 -o smtpd_tls_wrappermode=yes
 -o smtpd_sasl_auth_enable=yes

and restarted postfix

And tried to telnet into localhost 465.  All I get is:

telnet test1.test.htt-consult.com 465
Trying 208.83.67.180...
Connected to test1.test.htt-consult.com.
Escape character is '^]'.


The one pointer I have found so far on telneting into 465 shows that I 
should have also gotten a:


220   ESMTP Postfix

sending a 'ehlo' results in the connection closing.

Other smtpd main.cf options previously set are:

smtpd_use_tls = yes
smtpd_tls_loglevel = 1
smtpd_tls_received_header = yes
smtpd_tls_session_cache_timeout = 3600s
smtpd_tls_key_file = /etc/pki/tls/private/test1.test.htt-consult.com.key
smtpd_tls_cert_file = /etc/pki/tls/certs/test1.test.htt-consult.com.crt


Thank you for any assistance.

Re: content_filter and firewall rules

[Robert Moskowitz]

On 02/04/2013 03:04 PM, Viktor Dukhovni wrote:

On Mon, Feb 04, 2013 at 01:46:37PM -0500, Robert Moskowitz wrote:


It seems from my limited testing that with the content_filter option of:

content_filter=amavisfeed:[127.0.0.1]:10024

I don't need an iptables rule for port 10024, as there is no
firewall blocking of localhost connection to ports.

As long as I don't do something stupid like:

content_filter=amavisfeed:myserver.com:10024

The something stupid is configuring amavis to listen on a public
IP address (or equivalently the wildcard 0.0.0.0 address). How you
connect to it from Postfix is not important, but if connecting to
the public IP address works from Postfix, then it likely works for
anyone else not explicitly blocked by a firewall, and this is bad.


I figured that and 127.0.0.1 is not exposed.  And my current setup only 
has ports 10024 and 10025 listening on 127.0.0.1.  So I have avoided 
really stupid.




So configure Amavis correctly, and the rest takes care of itself.


Define correctly.  It seems that a number of articles I have found 
recommend using 127.0.0.1.  You seem to be recommending something else 
and I am interested in learning more.





Same with the 10025 injection back into postfix from the content filter.

Just no reason to open up 10024  10025.

Have I got this correct?

Mostly, but the correct configuration in question is always in
fact a listener configuration rather than a client configuration,
the client is then configured to talk to a securely configured
listener.

With LMTP filters, Postfix can talk to unix-domain sockets, which
can be protected also against unauthorized local users. A TLS-enabled
filter SMTP or LMTP could also require client certs (and use an eNULL
cipher-suite).


Can you point me to some examples?  What I have done so far has been 
guided by a few howtos that probably all have the same heritage.


master.cf has:

amavisfeed unix-   -   n-  2 lmtp
-o lmtp_data_done_timeout=1200
-o lmtp_send_xforward_command=yes
-o disable_dns_lookups=yes
-o max_use=20


and for 'injection back':

127.0.0.1:10025 inet n-   n   -   - smtpd
-o content_filter=
-o smtpd_delay_reject=no
-o smtpd_client_restrictions=permit_mynetworks,reject
-o smtpd_helo_restrictions=
-o smtpd_sender_restrictions=
-o smtpd_recipient_restrictions=permit_mynetworks,reject
-o smtpd_data_restrictions=reject_unauth_pipelining
-o smtpd_end_of_data_restrictions=
-o smtpd_restriction_classes=
-o mynetworks=127.0.0.0/8
-o smtpd_error_sleep_time=0
-o smtpd_soft_error_limit=1001
-o smtpd_hard_error_limit=1000
-o smtpd_client_connection_count_limit=0
-o smtpd_client_connection_rate_limit=0
-o 
receive_override_options=no_header_body_checks,no_unknown_recipient_checks,no_milters,no_address_mappings

-o local_header_rewrite_clients=
-o smtpd_milters=
-o local_recipient_maps=
-o relay_recipient_maps=

and finally in main.cf

content_filter=amavisfeed:[127.0.0.1]:10024

I would be more than happy to move away from an IP port approach (even 
localhost) to a unix-domain approach.

Re: Testing out SMTPS

[Robert Moskowitz]

On 02/04/2013 03:41 PM, Stan Hoeppner wrote:

On 2/4/2013 12:27 PM, Robert Moskowitz wrote:


And from there I became aware that I probably don't have SMTPS (port
465) configured properly.  Actually at first I did not even have it set
up!  So I reread the readme:

Do you need SMTPS?  If so, for what?

I'm guessing you are blindly assuming you should have it because some
online mail server tester tests for it and told you yours wasn't
working.  Correct?


Well the online tester made me aware of it, and some of my clients are 
stuck with Outlook Express, thus my interest in it.


The online tester is rather 'dumb' as it does not consider that starttls 
is available as well.  Of course that means all of the POP clients are 
properly configured to use it for sending mail and thus not expose their 
identities.





I've been using Postfix for ~8 years and I've never used SMTPS, simply
because I've never needed it.  Only enable/configure what you need, no more.

I have to look some more at what I currently have and what my few OE 
users are doing.

Re: Testing out SMTPS

[Robert Moskowitz]

On 02/04/2013 03:47 PM, Noel Jones wrote:

On 2/4/2013 12:27 PM, Robert Moskowitz wrote:

I am into final tuning of my mail server, and I greatly appreciate
all the help I have received from the many lists I have had to go to
for help.  I am now at actual external testing, starting out with
some free mail test servers.  Right now I am trying out:

http://www.emailsecuritygrader.com

And from there I became aware that I probably don't have SMTPS (port
465) configured properly.  Actually at first I did not even have it
set up!  So I reread the readme:

http://www.postfix.org/TLS_README.html

And add:

/etc/postfix/main.cf
smtpd_tls_security_level = may
smtpd_tls_session_cache_database = btree:/var/lib/postfix/smtpd_scache

/etc/postfix/master.cf:
smtpsinet  n   -   n   -   -   smtpd
  -o smtpd_tls_wrappermode=yes
  -o smtpd_sasl_auth_enable=yes

The smtps port should be reserved for authorized users only -- just
like the submission port -- and never used for general-purpose email.

Generally you would add something like
   -o smtpd_recipient_restrictions=$submission_recipient_restrictions


I will look into this.  My setup uses virutal domains and mysql for the 
users, so a list may be contrived.  But also the implication is that 
users would have to ask me for this method of connectivity which has its 
merits.




and then in main.cf add
submission_recipient_restrictions =
   permit_sasl_authenticated
   reject


thanks I will review this.





and restarted postfix

And tried to telnet into localhost 465.  All I get is:


This is an encrypted connection and can't be tested with telnet.
You can test it with openssl:

openssl s_client -connect server.example.com:465


Grumple.  I did this to test out secure IMAP for dovecot.  Obvious once 
my nose is stuck in it.  Thanks.



If you get the postfix greeting banner, it's working properly.

But be aware that smtps is deprecated and you probably shouldn't
bother enabling it unless you need it to support legacy clients.


Good to know.  I kind of got that feeling from the TLS_README that it 
was for older OE clients, and I have one of those.  A reason for them to 
move up.  Hopefully.

Re: Testing out SMTPS

[Robert Moskowitz]

On 02/04/2013 04:03 PM, btb wrote:

On 2013.02.04 13.27, Robert Moskowitz wrote:

http://www.emailsecuritygrader.com


as with most helpful websites like this, this one is perpetuating 
misinformation.  smtps has long since been deprecated, having been 
superseded by starttls.  it also would appear to perpetuate the 
behavior of offering submission service via port 25, which is largely 
discouraged.


And blocked at many hotspots.




And from there I became aware that I probably don't have SMTPS (port
465) configured properly.


with reference to the above, instead, configure a proper 
submission+starttls service [port 587].  there is an example included 
in the master.cf config file which comes with postfix.


And I do have that configured.



these days, new implementation of smtps should be restricted to 
existing environments in which smtps is already in use by clients.  
even then, it really should be used only until clients have been 
converted to use proper submission+starttls.


And tried to telnet into localhost 465.

telnet is not suitable for testing things which employ this sort of 
encryption. instead, use something like openssl s_client or gnutls-cli


Got that.  thanks.




The one pointer I have found so far on telneting into 465 shows that I
should have also gotten a:

220   ESMTP Postfix

sending a 'ehlo' results in the connection closing.


this is misinformation.  with smtps, encryption must be established 
before any smtp related dialog can occur.  telnet does not do this 
sort of encryption.


And I looked into my logs for the emailsecuritygrader connections and it 
sure seemed to be connecting with something equivalent to telnet!  Well 
more testing will tell.