Re: 3.1.4 Compiled and Installed on OSX Sierra 10.12.2 Successful.

[Larry Stone]

> On Feb 18, 2017, at 10:39 AM, Larry Stone  wrote:
> 
>> 
>> On Feb 18, 2017, at 8:11 AM, Viktor Dukhovni  
>> wrote:
>> 
> 
>> If you have a pre-Sierra MacOS/X machine, perhaps building 3.1.4 there
>> and copying the binaries will yield the same behaviour you see with
>> 3.1.1?
> 
> I do but it’s all the way back at Mavericks (10.9.5). I recently 
> recommissioned an old MacBookPro (I never could get it to upgrade beyond 
> where it is) to use as a Fax Server since Sierra discontinued support for USB 
> Fax Modems. At some point, I’ll try building 3.1.4 there and see what happens 
> and if I can move the built files.

Tried and it works. So now running 3.1.4 on Sierra with the build having been 
done on Mavericks.

But now, and longer term, see if there’s a way to build under Sierra with the 
old syslog logging.
 
-- 
Larry Stone
lston...@stonejongleux.com

Re: 3.1.4 Compiled and Installed on OSX Sierra 10.12.2 Successful.

[Larry Stone]

> On Feb 18, 2017, at 8:11 AM, Viktor Dukhovni  
> wrote:
> 
> On Sat, Feb 18, 2017 at 07:37:27AM -1000, Larry Stone wrote:
> 
>> Viktor, did you ever figure out the logging issue?
> 
> No.  Insufficient time to figure out the innards of the new Apple
> logging subsystem.  My laptop is just for Postfix development, so
> the issue has not as yet warranted much effort on my part.
> 
>> I just tried upgrading my test system to Postfix 3.1.4 (from 3.1.1) and
>> the logging started to go to the new Apple logging system. Immediately
>> fell back to 3.1.1 and the logging is back to /var/log/mail.log.
> 
> Is the 3.1.1 build also your own?  Built under the same O/S version?

Arg! My usual approach to OS X upgrades is to first clone the disk and 
upgrade the copy as a test. I must have done my test rebuild of Postfix on the 
clone, saw that it was functional but missed the logging issue, then when I 
upgraded for real, never rebuilt Postfix since the old version built under El 
Capitan ran fine. Rebuilding 3.1.1 under Sierra also uses the new MacOS logging 
so fell back again to the El Capitan built version.

> If you have a pre-Sierra MacOS/X machine, perhaps building 3.1.4 there
> and copying the binaries will yield the same behaviour you see with
> 3.1.1?

I do but it’s all the way back at Mavericks (10.9.5). I recently recommissioned 
an old MacBookPro (I never could get it to upgrade beyond where it is) to use 
as a Fax Server since Sierra discontinued support for USB Fax Modems. At some 
point, I’ll try building 3.1.4 there and see what happens and if I can move the 
built files.

But, I’m probably good with 3.1.1 for a long time. My Postfix is no longer 
Internet facing (I used to run my own mail server but now have that contracted 
out to an ISP) so I just use Postfix to get internally generated email 
(including the aforementioned fax server which emails incoming faxes) out to my 
ISP.

-- 
Larry Stone
lston...@stonejongleux.com

Re: 3.1.4 Compiled and Installed on OSX Sierra 10.12.2 Successful.

[Viktor Dukhovni]

On Sat, Feb 18, 2017 at 07:37:27AM -1000, Larry Stone wrote:

> Viktor, did you ever figure out the logging issue?

No.  Insufficient time to figure out the innards of the new Apple
logging subsystem.  My laptop is just for Postfix development, so
the issue has not as yet warranted much effort on my part.

> I just tried upgrading my test system to Postfix 3.1.4 (from 3.1.1) and
> the logging started to go to the new Apple logging system. Immediately
> fell back to 3.1.1 and the logging is back to /var/log/mail.log.

Is the 3.1.1 build also your own?  Built under the same O/S version?

> My initial make command (based on what you’ve previously suggested is):
> make -f Makefile.init makefiles CCARGS='-DUSE_TLS -I/usr/local/ssl/include \
> -DUSE_SASL_AUTH \
> -DUSE_CYRUS_SASL \
> -I/usr/local/include/sasl \
> -DDEF_SERVER_SASL_TYPE=\"dovecot\"\
> -DDEF_COMMAND_DIR=\"/usr/local/sbin\"\
> -DDEF_CONFIG_DIR=\"/usr/local/etc/postfix\"\
> -DDEF_DAEMON_DIR=\"/usr/local/libexec/postfix\"\
> -DHAS_PCRE -I/usr/local/include' \
> AUXLIBS='-L/usr/local/lib -lpcre -L/usr/local/ssl/lib -lssl -lcrypto \
> -L/usr/local/lib -lsasl2’

Looks ok.  Postfix does not introduce new features in patch releases,
so there should be nothing different in this regard between 3.1.1 and
3.1.4.  The only thing that comes to mind that your build of 3.1.4 is
newer.  Perhaps older binaries use an older syslog API?

If you have a pre-Sierra MacOS/X machine, perhaps building 3.1.4 there
and copying the binaries will yield the same behaviour you see with
3.1.1?

-- 
Viktor.

Re: Can anyone expain this difference between almost identical postfix installations

[/dev/rob0]

On Sat, Feb 18, 2017 at 05:43:03PM +, Chris Green wrote:
> I am trying to diagnose why messages from on system fail to arrive
> whereas identical messages from another similar system arrive
> successfully.
> 
> Both systems are single board computers running postfix 2.9.6 under
> Debian.  The main.cf on both systems is identical.  Both systems are
> connecting to the same SMTP server for relaying.
> 
> On the system where the message is sent and received successfully I
> see (in /var/log/mail.log):-
> Feb 18 17:32:51 pi postfix/pickup[25898]: 2009B22C52: uid=1000 
> from=
> Feb 18 17:32:51 pi postfix/cleanup[25978]: 2009B22C52: 
> message-id=<20170218173251.2009b22...@pi.zbmc.eu>
> Feb 18 17:32:51 pi postfix/qmgr[21159]: 2009B22C52: from=, 
> size=294, nrcpt=1 (queue active)
> Feb 18 17:32:52 pi postfix/smtp[25980]: 2009B22C52: to=, 
> relay=mail3.gridhost.co.uk[95.142.156.18]:587, delay=0.97, 
> delays=0.15/0.11/0.36/0.35, 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 08DEC26AEC71)

Here the relayhost seems to be using a content filter, and on the 
line above is reporting what it has heard through the filter.  It 
also reports the queue ID on the other side of the filter, to wit:
"08DEC26AEC71".

> Feb 18 17:32:52 pi postfix/qmgr[21159]: 2009B22C52: removed
> 
> 
> 
> On the system that appears to send OK but the message never
> reaches its destination I see:-
> 
> Feb 18 18:32:18 odin postfix/pickup[15648]: 05E963BC3: uid=1001 
> from=
> Feb 18 18:32:18 odin postfix/cleanup[15989]: 05E963BC3: 
> message-id=<20170218173218.05e963...@odin.zbmc.eu>
> Feb 18 18:32:18 odin postfix/qmgr[14084]: 05E963BC3: 
> from=, size=296, nrcpt=1 (queue active)
> Feb 18 18:32:19 odin postfix/smtp[15991]: 05E963BC3: to=, 
> relay=mail3.gridhost.co.uk[95.142.156.18]:587, delay=1.2, 
> delays=0.22/0.11/0.65/0.19, dsn=2.0.0,
> status=sent (250 2.0.0 Ok: queued as EDA7EE0C39)

Here we didn't get anything from the content filter.  The answer of 
the question, "Why not?" is probably in the logs on the relayhost.

> Feb 18 18:32:19 odin postfix/qmgr[14084]: 05E963BC3: removed
> 
> 
> Does that 'queued as EDA7EE0C39' in the second case mean that the 
> message has been put on a queue rather than being sent?  But why?  
> The messages are virtually identical, the destination address is 
> the same, etc.

If you don't control the relayhost, talk to the admin there.
-- 
  http://rob0.nodns4.us/
  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:

Can anyone expain this difference between almost identical postfix installations

[Chris Green]

I am trying to diagnose why messages from on system fail to arrive
whereas identical messages from another similar system arrive
successfully.

Both systems are single board computers running postfix 2.9.6 under
Debian.  The main.cf on both systems is identical.  Both systems are
connecting to the same SMTP server for relaying.

On the system where the message is sent and received successfully I
see (in /var/log/mail.log):-
Feb 18 17:32:51 pi postfix/pickup[25898]: 2009B22C52: uid=1000 from=
Feb 18 17:32:51 pi postfix/cleanup[25978]: 2009B22C52: 
message-id=<20170218173251.2009b22...@pi.zbmc.eu>
Feb 18 17:32:51 pi postfix/qmgr[21159]: 2009B22C52: from=, 
size=294, nrcpt=1 (queue active)
Feb 18 17:32:52 pi postfix/smtp[25980]: 2009B22C52: to=, 
relay=mail3.gridhost.co.uk[95.142.156.18]:587, delay=0.97, 
delays=0.15/0.11/0.36/0.35, 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 08DEC26AEC71)
Feb 18 17:32:52 pi postfix/qmgr[21159]: 2009B22C52: removed



On the system that appears to send OK but the message never reaches its
destination I see:-

Feb 18 18:32:18 odin postfix/pickup[15648]: 05E963BC3: uid=1001 from=
Feb 18 18:32:18 odin postfix/cleanup[15989]: 05E963BC3: 
message-id=<20170218173218.05e963...@odin.zbmc.eu>
Feb 18 18:32:18 odin postfix/qmgr[14084]: 05E963BC3: from=, 
size=296, nrcpt=1 (queue active)
Feb 18 18:32:19 odin postfix/smtp[15991]: 05E963BC3: to=, 
relay=mail3.gridhost.co.uk[95.142.156.18]:587, delay=1.2, 
delays=0.22/0.11/0.65/0.19, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 
EDA7EE0C39)
Feb 18 18:32:19 odin postfix/qmgr[14084]: 05E963BC3: removed


Does that 'queued as EDA7EE0C39' in the second case mean that the message
has been put on a queue rather than being sent?  But why?  The messages
are virtually identical, the destination address is the same, etc.


If I send a message from the unsuccessful system to a *different* destination
then it arrives OK, but the messages in the mail.log are the same as above.

-- 
Chris Green

Re: 3.1.4 Compiled and Installed on OSX Sierra 10.12.2 Successful.

[Larry Stone]

Viktor, did you ever figure out the logging issue? I just tried upgrading my 
test system to Postfix 3.1.4 (from 3.1.1) and the logging started to go to the 
new Apple logging system. Immediately fell back to 3.1.1 and the logging is 
back to /var/log/mail.log.

My initial make command (based on what you’ve previously suggested is):
make -f Makefile.init makefiles CCARGS='-DUSE_TLS -I/usr/local/ssl/include \
-DUSE_SASL_AUTH \
-DUSE_CYRUS_SASL \
-I/usr/local/include/sasl \
-DDEF_SERVER_SASL_TYPE=\"dovecot\"\
-DDEF_COMMAND_DIR=\"/usr/local/sbin\"\
-DDEF_CONFIG_DIR=\"/usr/local/etc/postfix\"\
-DDEF_DAEMON_DIR=\"/usr/local/libexec/postfix\"\
-DHAS_PCRE -I/usr/local/include' \
AUXLIBS='-L/usr/local/lib -lpcre -L/usr/local/ssl/lib -lssl -lcrypto \
-L/usr/local/lib -lsasl2’

-- 
Larry Stone
lston...@stonejongleux.com





> On Jan 3, 2017, at 6:51 AM, Larry Stone  wrote:
> 
> I seem to be missing a couple of messages in this thread but I upgraded my 
> laptop (I use it as a test system as well) to Sierra over the weekend and am 
> getting normal logging without doing anything special. My Postfix is in 
> /usr/local (I moved completely away from the Apple directories for the server 
> stuff I do).
> 
> Postfix (I'm still on 3.1.1) ran as previously built (no need to re-make 
> under Sierra although I have tested that it builds OK) (in fact all the 
> server software I now run runs as previously built).
> 
> So maybe the question is what did you (Viktor) do that is causing the 
> different logging format? Did you upgrade from El Capitan or is it a fresh 
> install? It looks like yours are going through Apple's new (and IMHO not as 
> good) log facility rather than syslog (that's the same format I see for 
> TimeMachine log messages extracted from the new log facility; e.g.
> 2017-01-01 06:18:18.094145-0600  localhost backupd[13915]: (TimeMachine) 
> [com.apple.TimeMachine.TMLogInfo] Backup completed successfully.
> 
> -- Larry Stone
>   lston...@stonejongleux.com
> 
> On Tue, 3 Jan 2017, Viktor Dukhovni wrote:
> 
>> 
>>> On Jan 3, 2017, at 10:33 AM, Robert Chalmers  wrote:
>>> 
>>> Do you mean like this ? where ?postfix? shows up.?
>>> 
>>> Jan  3 09:58:20 zeus postfix/smtpd[31070]: connect from unknown[115.71.5.5]
>> 
>> Yes.  What did you do to get real syslog messages with MacOS/X Sierra?
>> 
 I get output similar to:
 
  2017-01-03 10:11:13.946120-0500  localhost smtpd[7301]: 
 (libpostfix-util.dylib) disconnect from localhost[127.0.0.1] ehlo=1 
 starttls=0/1 commands=1/2
 
 In which the "postfix/" syslog_name is nowhere in sight.  Makes 
 multi-instance
 logging rather opaque, and breaks the usual way to distinguish submission 
 logging
 from port 25 logging, ...
>> 
>> --
>>  Viktor.
>> 
>> 

Re: MySQL stored-procedure support for Postfix 3.2

[jl]

On 2016-12-27 09:45, John Fawcett wrote:

On 12/26/2016 10:35 PM, Wietse Venema wrote:

John Fawcett:

so long as the loop continues in the presence of a zero return
code from mysql_next_result() and mysql_store_result is called for
each one we will stay in sync. With the break above we will be ok,
since the loop stops only when there are no more results -1 normal
condition from mysql_next_result or >0 error condition from
mysql_next_result via the break.

I further reduced the number of state variables, moved the "no
result" check out of the loop, included the database name in warning
messages, and added support for "require_result_set = no" to avoid
the need for dummy SELECT statements in stored procedures.

Please check out postfix-3.2-20161226-nonprod. As you will see,
code diffs not useful at this point.

Wietse


Thanks. I ran it through my tests and it produces expected results for
queries and stored procedures. I'll run it for a while (using queries)
and report back any issues.

John


I wan't to thank you guys for integrating stored procedure support into 
postfix. The amount of thought put into this relatively minor task was 
impressive to me, but I suppose that is the reason why postfix is 
considered such a safe and stable system. I guess this mentality is what 
enabled postfix to compete and grow alongside other MTAs over the last 
two decades.


I use the latest evolution of the mysql code in my production system, 
including the "require_result_set=no" flag and it performs flawlessly. 
My primarily email volume consists of my private mail but I forward 
emails for an association, hence the complex setup


Thanks again,

Joel

Re: Different treatment of ports 465 and 587 between postfix versions 2.9 and 3.1

[Chris Green]

On Sat, Feb 18, 2017 at 11:30:08PM +1300, Peter wrote:
> On 18/02/17 22:56, Chris Green wrote:
> > The older (2.9.6) and newer (3.1.0) postfix versions that I'm using
> > are connecting to the same smarthost.  I don't seem to be able to
> > connect from the 3.1.0 version to the submission service on 587 for
> > some reason.
> 
> At a WAG you have smtp_tls_wrappermode set to yes.  Wrappermode is for
> SMTPS only and does not work for STARTTLS so you need to remove that
> setting.
> 
> At a guess you probably also set it to yes in your postfix 2.9 but that
> setting is not supported in 2.9 so it is simply ignored and wrappermode
> is not set.
> 
> > Is it that 'smtp_tls_wrappermode = yes' that I need to remove?  I can
> > see little other difference between the configurations.
> 
> Correct.
> 
> Note that SMTPS (port 465) requires wrappermode (not supported in 2.9)
> or tunnelling through stunnel.  STARTTLS (587) requires that wrappermode
> not be set.
> 
> 
Thanks.  I think I'll disappear now, for a while at least.  :-)

-- 
Chris Green

Re: Different treatment of ports 465 and 587 between postfix versions 2.9 and 3.1

[Peter]

On 18/02/17 22:56, Chris Green wrote:
> The older (2.9.6) and newer (3.1.0) postfix versions that I'm using
> are connecting to the same smarthost.  I don't seem to be able to
> connect from the 3.1.0 version to the submission service on 587 for
> some reason.

At a WAG you have smtp_tls_wrappermode set to yes.  Wrappermode is for
SMTPS only and does not work for STARTTLS so you need to remove that
setting.

At a guess you probably also set it to yes in your postfix 2.9 but that
setting is not supported in 2.9 so it is simply ignored and wrappermode
is not set.

> Is it that 'smtp_tls_wrappermode = yes' that I need to remove?  I can
> see little other difference between the configurations.

Correct.

Note that SMTPS (port 465) requires wrappermode (not supported in 2.9)
or tunnelling through stunnel.  STARTTLS (587) requires that wrappermode
not be set.


Peter

Re: Different treatment of ports 465 and 587 between postfix versions 2.9 and 3.1

[Chris Green]

On Fri, Feb 17, 2017 at 06:11:44PM -0500, Viktor Dukhovni wrote:
> 
> > On Feb 17, 2017, at 5:33 PM, Chris Green  wrote:
> > 
> > OK, so the older version is using SMTP STARTTLS which runs on port 587
> 
> This is how TLS has worked in MTA-to-MTA SMTP for the last > 15 years.
> 
>   https://tools.ietf.org/html/rfc3207
> 
> > and the newer (>=3) version is using TLS directly on port 465.
> 
> No, Postfix 3.0 and later *also* support SMTP over TLS as used
> by some systems on port 465.  The submission service on 587 and
> the relay service on port 25 continue to support STARTTLS.
> 
> To use submission on port 587 the server needs to provide that
> service.  If a server only supports "smtps" on 465, then that's
> what you need to use.
> 
The older (2.9.6) and newer (3.1.0) postfix versions that I'm using
are connecting to the same smarthost.  I don't seem to be able to
connect from the 3.1.0 version to the submission service on 587 for
some reason.  Do I have to explicitly say I want to use STARTTLS as
well as connecting to port 587?

The 3.1.0 configuration is currently:-

smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated
defer_unauth_destination
myhostname = esprimo.zbmc.eu
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
myorigin = zbmc.eu
mydestination = zbmc.eu esprimo.zbmc.eu, esprimo, chris.zbmc.eu
relayhost = [mail3.gridhost.co.uk]:465
mynetworks = 127.0.0.0/8 [:::127.0.0.0]/104 [::1]/128
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = all
inet_protocols = ipv4
smtp_sasl_auth_enable = yes
smtp_tls_wrappermode = yes
smtp_tls_security_level = encrypt
smtp_sasl_tls_security_options = noanonymous
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
message_size_limit = 12048
compatibility_level = 2

What do I need to change to connect successfully to 587?  The 2.9.6
ones already connect successfully to [mail3.gridhost.co.uk]:587 so it
is possible.

Is it that 'smtp_tls_wrappermode = yes' that I need to remove?  I can
see little other difference between the configurations.

Thanks for all the help/explanations so far, I'm really not very good
at all this!

-- 
Chris Green