Re: Starting postfix

[Stan Hoeppner]

Patrick Ben Koetter put forth on 2/25/2011 4:20 PM:
> * lst_ho...@kwsoft.de :
>> Zitat von Wietse Venema :
>>> This is now running on an Ubuntu virtual machine.
>>
>> Cool...
>> And BTW i also have never seen Postfix die. It is one of the most
>> stable non-trivial software systems i have seen until now.
> 
> Postfix is frustrating. At first tt's fun because it is setup easily. But once
> you've done, you don't need to touch it again. It simply sits there and does
> its job. No more fun. Nothing to play with. Very frustrating... ;)

On the bright side, this stability freed up time allowing you to write a
book about it.  :)

-- 
Stan

Re: [PATCH] postfix won't build on FREEBSD 7.2+

[Matthias Andree]

Am 26.02.2011 00:52, schrieb Sahil Tandon:
> On Fri, 2011-02-25 at 10:50:45 +0100, kristof.vans...@telenet.be wrote:
> 
>> This problem exist in the 2.7 and 2.8 branch: 
>>
>> In file included from attr_clnt.c:77: 
>> /usr/include/unistd.h:329: error: conflicting types for 'closefrom' 
>> ./sys_defs.h:1399: error: previous declaration of 'closefrom' was here 
>> *** Error code 1 
>>
>> Stop in /home/src/postfix-2.7.2/src/util. 
>> *** Error code 1 
>>
>> Stop in /home/src/postfix-2.7.2. 
> 
> Ah, you are not using the ports infrastructure, in which sys_defs.h has
> been patched to be aware of the closefrom() system call in 702104 and
> other FreeBSD versions.
> 
> FWIW, this issue was discussed[1] on -devel a few months ago.

Maybe, but pulling the patch into the upstream sources would seem right
to put this refinement where it belongs, no?

Postfix/Upstart, the final conclusion

[Wietse Venema]

People, this week I have gone through a several iterations and
several degrees of Postfix-upstart integration.

The short answer is that only one option is practical at the moment.
The longer answer is summarized below.

Wietse

There are three major levels of Postfix-upstart integration.

- Boot-only integration: use upstart to start/stop Postfix at
  boot/shutdown time and nowhere else.

  This option is preferred. It requires no changes to Postfix,
  and it does not affect Postfix reliability.  Postfix comes
  with its own daemon that (re)spawns mail processes as needed.
  This small program has proven to be extremely reliable over
  the past 14 years.

- Fake integration: this variant involves running a dummy process
  directly under upstart. This program translates SIGHUP/SIGTERM
  signals from upstart into postfix reload/stop commands.

  This option has no benefits over "boot-only integration", as
  observed by others; it just increases complexity.  On the
  positive side, it is fully compatible with existing Postfix
  code for single-instance and multi-instance support.

- Full integration: all Postfix master daemons run directly under
  upstart.  This requires re-implementing the Postfix start/stop
  commands and multi-instance provisioning commands, so that they
  execute requests through initctl(8).

  This option is not preferred.  The code that executes requests
  through initctl(8) needs to be maintained in parallel with
  the existing management code, because many supported systems
  do not use upstart. Another downside is that the longer code
  paths through initctl(8) do not necessarily make Postfix more
  reliable.

Unfortunately, a lot of energy has gone into debating the next
option on- and off-list:

- Broken integration: one proposed variant runs one Postfix master
  daemon directly under upstart. It breaks the Postfix start/stop
  commands and multi-instance support, because it lacks the steps
  required for full initctl(8) integration (see previous item).
  I tried several variants along this line. They were less broken,
  but they still violated the principle of least astonishment.

I don't want to spend more words on this heated debate, except for
the following:

- If a new feature is important, then it should be developed in
  the context of the Postfix development release, that is, Postfix
  2.9.

- There is no need to distribute private branches of stable Postfix
  releases that break major Postfix features.

Re: [PATCH] postfix won't build on FREEBSD 7.2+

[Wietse Venema]

Matthias Andree:
> Am 26.02.2011 00:52, schrieb Sahil Tandon:
> > On Fri, 2011-02-25 at 10:50:45 +0100, kristof.vans...@telenet.be wrote:
> > 
> >> This problem exist in the 2.7 and 2.8 branch: 
> >>
> >> In file included from attr_clnt.c:77: 
> >> /usr/include/unistd.h:329: error: conflicting types for 'closefrom' 
> >> ./sys_defs.h:1399: error: previous declaration of 'closefrom' was here 
> >> *** Error code 1 
> >>
> >> Stop in /home/src/postfix-2.7.2/src/util. 
> >> *** Error code 1 
> >>
> >> Stop in /home/src/postfix-2.7.2. 
> > 
> > Ah, you are not using the ports infrastructure, in which sys_defs.h has
> > been patched to be aware of the closefrom() system call in 702104 and
> > other FreeBSD versions.
> > 
> > FWIW, this issue was discussed[1] on -devel a few months ago.
> 
> Maybe, but pulling the patch into the upstream sources would seem right
> to put this refinement where it belongs, no?

I don't take patches that retroactively break the build on my
FreeBSD 7.1 development system, hence my nasty comment in sys_defs.h.

If someone can figure out a patch that does not retroactively break
the build, then I am interested.

Wietse

Re: Postfix/Upstart, the final conclusion

[Reindl Harald]

Thank you for your informations and very good documentation!

Has anybody an eye to systemd/postfix because systemd will
replace sysvinit/upstart in the upcoming Fedora 16 and
so also in future RHEL-Versions and maybe replace
upstart/sysvinit sooner or later in other distributions
because the design of systemd seems to be really good

Am 27.02.2011 19:01, schrieb Wietse Venema:
> People, this week I have gone through a several iterations and
> several degrees of Postfix-upstart integration.
> 
> The short answer is that only one option is practical at the moment.
> The longer answer is summarized below.
> 
>   Wietse
> 
> There are three major levels of Postfix-upstart integration.
> 
> - Boot-only integration: use upstart to start/stop Postfix at
>   boot/shutdown time and nowhere else.
> 
>   This option is preferred. It requires no changes to Postfix,
>   and it does not affect Postfix reliability.  Postfix comes
>   with its own daemon that (re)spawns mail processes as needed.
>   This small program has proven to be extremely reliable over
>   the past 14 years.
> 
> - Fake integration: this variant involves running a dummy process
>   directly under upstart. This program translates SIGHUP/SIGTERM
>   signals from upstart into postfix reload/stop commands.
> 
>   This option has no benefits over "boot-only integration", as
>   observed by others; it just increases complexity.  On the
>   positive side, it is fully compatible with existing Postfix
>   code for single-instance and multi-instance support.
> 
> - Full integration: all Postfix master daemons run directly under
>   upstart.  This requires re-implementing the Postfix start/stop
>   commands and multi-instance provisioning commands, so that they
>   execute requests through initctl(8).
> 
>   This option is not preferred.  The code that executes requests
>   through initctl(8) needs to be maintained in parallel with
>   the existing management code, because many supported systems
>   do not use upstart. Another downside is that the longer code
>   paths through initctl(8) do not necessarily make Postfix more
>   reliable.
> 
> Unfortunately, a lot of energy has gone into debating the next
> option on- and off-list:
> 
> - Broken integration: one proposed variant runs one Postfix master
>   daemon directly under upstart. It breaks the Postfix start/stop
>   commands and multi-instance support, because it lacks the steps
>   required for full initctl(8) integration (see previous item).
>   I tried several variants along this line. They were less broken,
>   but they still violated the principle of least astonishment.
> 
> I don't want to spend more words on this heated debate, except for
> the following:
> 
> - If a new feature is important, then it should be developed in
>   the context of the Postfix development release, that is, Postfix
>   2.9.
> 
> - There is no need to distribute private branches of stable Postfix
>   releases that break major Postfix features.

-- 

Reindl Harald
the lounge interactive design GmbH
A-1060 Vienna, Hofmühlgasse 17
CTO / software-development / cms-solutions
p: +43 (1) 595 3999 33, m: +43 (676) 40 221 40
icq: 154546673, http://www.thelounge.net/



signature.asc
Description: OpenPGP digital signature

Re: Postfix/Upstart, the final conclusion

[Wietse Venema]

Reindl Harald:
> Thank you for your informations and very good documentation!

Please fix your mail reader. 

My posting had:

To: Postfix users 
Reply-To: Postfix users 

Yet your response was:

To: Postfix users 
CC: Wietse Venema 

Please respect the Reply-To: header, at least on this mailing list.

Wietse

Re: [PATCH] postfix won't build on FREEBSD 7.2+

[Jerry]

On Sun, 27 Feb 2011 18:33:39 +0100
Matthias Andree  articulated:

> Am 26.02.2011 00:52, schrieb Sahil Tandon:
> > On Fri, 2011-02-25 at 10:50:45 +0100, kristof.vans...@telenet.be
> > wrote:
> > 
> >> This problem exist in the 2.7 and 2.8 branch: 
> >>
> >> In file included from attr_clnt.c:77: 
> >> /usr/include/unistd.h:329: error: conflicting types for
> >> 'closefrom' ./sys_defs.h:1399: error: previous declaration of
> >> 'closefrom' was here *** Error code 1 
> >>
> >> Stop in /home/src/postfix-2.7.2/src/util. 
> >> *** Error code 1 
> >>
> >> Stop in /home/src/postfix-2.7.2. 
> > 
> > Ah, you are not using the ports infrastructure, in which sys_defs.h
> > has been patched to be aware of the closefrom() system call in
> > 702104 and other FreeBSD versions.
> > 
> > FWIW, this issue was discussed[1] on -devel a few months ago.
> 
> Maybe, but pulling the patch into the upstream sources would seem
> right to put this refinement where it belongs, no?

I use FreeBSD with Postfix via the ports system sans problems. Is there
some specific problem you are experiencing using that method? Unlike
other distros, FreeBSD usually has the latest stable and development
versions available within a few days of the product's actual release
date. I don't know of any other distro that makes available updates to
Postfix anywhere near as quickly as that. Some (names with held to
protect the guilty) as still issuing versions that have been
superseded years ago as their latest offering.

-- 
Jerry ✌
postfix-u...@seibercom.net
_
TO REPORT A PROBLEM see http://www.postfix.org/DEBUG_README.html#mail
TO (UN)SUBSCRIBE see http://www.postfix.org/lists.html

Atlanta makes it against the law to tie a giraffe to a telephone pole
or street lamp.

Re: Postfix/Upstart, the final conclusion

[Jerry]

On Sun, 27 Feb 2011 13:33:49 -0500 (EST)
Wietse Venema  articulated:

> Reindl Harald:
> > Thank you for your informations and very good documentation!
> 
> Please fix your mail reader. 
> 
> My posting had:
> 
> To: Postfix users 
> Reply-To: Postfix users 
> 
> Yet your response was:
> 
> To: Postfix users 
> CC: Wietse Venema 
> 
> Please respect the Reply-To: header, at least on this mailing list.
> 
>   Wietse

Thanks Wietse! I have complained on numerous lists regarding the
gratuitous use of CCing everyone even though I have specifically
requested NOT to be CC'd with virtually no effect. Even asking the list
owners to remove those individuals has proven futile.

-- 
Jerry ✌
postfix-u...@seibercom.net
_
TO REPORT A PROBLEM see http://www.postfix.org/DEBUG_README.html#mail
TO (UN)SUBSCRIBE see http://www.postfix.org/lists.html

Re: Postfix/Upstart, the final conclusion

[Reindl Harald]

Am 27.02.2011 20:24, schrieb Jerry:
> On Sun, 27 Feb 2011 13:33:49 -0500 (EST)
> Wietse Venema  articulated:
> 
>> Reindl Harald:
>>> Thank you for your informations and very good documentation!
>>
>> Please fix your mail reader. 
>>
>> My posting had:
>>
>> To: Postfix users 
>> Reply-To: Postfix users 
>>
>> Yet your response was:
>>
>> To: Postfix users 
>> CC: Wietse Venema 
>>
>> Please respect the Reply-To: header, at least on this mailing list.
>>
>>  Wietse
> 
> Thanks Wietse! I have complained on numerous lists regarding the
> gratuitous use of CCing everyone even though I have specifically
> requested NOT to be CC'd with virtually no effect. Even asking the list
> owners to remove those individuals has proven futile.

sorry that was because normally i use "reply all" what is needed
on some mailing-lists which are sending the message with "from"
as the users address and if you use there "reply" only nobody on
the list will ever see a message



signature.asc
Description: OpenPGP digital signature

Re: [PATCH] postfix won't build on FREEBSD 7.2+

[Sahil Tandon]

On Sun, 2011-02-27 at 18:33:39 +0100, Matthias Andree wrote:

> Am 26.02.2011 00:52, schrieb Sahil Tandon:
> > On Fri, 2011-02-25 at 10:50:45 +0100, kristof.vans...@telenet.be wrote:
> > 
> >> This problem exist in the 2.7 and 2.8 branch: 
> >>
> >> In file included from attr_clnt.c:77: 
> >> /usr/include/unistd.h:329: error: conflicting types for 'closefrom' 
> >> ./sys_defs.h:1399: error: previous declaration of 'closefrom' was here 
> >> *** Error code 1 
> >>
> >> Stop in /home/src/postfix-2.7.2/src/util. 
> >> *** Error code 1 
> >>
> >> Stop in /home/src/postfix-2.7.2. 
> > 
> > Ah, you are not using the ports infrastructure, in which sys_defs.h has
> > been patched to be aware of the closefrom() system call in 702104 and
> > other FreeBSD versions.
> > 
> > FWIW, this issue was discussed[1] on -devel a few months ago.
> 
> Maybe, but pulling the patch into the upstream sources would seem right
> to put this refinement where it belongs, no?

I do not understand your response.  "Maybe" what?  The patch for
upstream has already been proposed in the link I pasted earlier in this
thread.  So, naturally, I agree that upstream is the correct place for
this "refinement".  When some iteration of it is incorporated by Wietse,
we'll just remove it from ports.

-- 
Sahil Tandon 

Re: [PATCH] postfix won't build on FREEBSD 7.2+

[Matthias Andree]

Am 27.02.2011 20:41, schrieb Sahil Tandon:
> On Sun, 2011-02-27 at 18:33:39 +0100, Matthias Andree wrote:
> 
>> Am 26.02.2011 00:52, schrieb Sahil Tandon:
>>> On Fri, 2011-02-25 at 10:50:45 +0100, kristof.vans...@telenet.be wrote:
>>>
 This problem exist in the 2.7 and 2.8 branch: 

 In file included from attr_clnt.c:77: 
 /usr/include/unistd.h:329: error: conflicting types for 'closefrom' 
 ./sys_defs.h:1399: error: previous declaration of 'closefrom' was here 
 *** Error code 1 

 Stop in /home/src/postfix-2.7.2/src/util. 
 *** Error code 1 

 Stop in /home/src/postfix-2.7.2. 
>>>
>>> Ah, you are not using the ports infrastructure, in which sys_defs.h has
>>> been patched to be aware of the closefrom() system call in 702104 and
>>> other FreeBSD versions.
>>>
>>> FWIW, this issue was discussed[1] on -devel a few months ago.
>>
>> Maybe, but pulling the patch into the upstream sources would seem right
>> to put this refinement where it belongs, no?
> 
> I do not understand your response.  "Maybe" what?  The patch for
> upstream has already been proposed in the link I pasted earlier in this
> thread.  So, naturally, I agree that upstream is the correct place for
> this "refinement".  When some iteration of it is incorporated by Wietse,
> we'll just remove it from ports.
> 

Yeah.  The simplest thing would be ditching FreeBSD 7.1 support (FreeBSD
7.1 will be discontinued after tomorrow).

Surely an upstream modification shouldn't introduce regressions either,
so let's not make too much noise about that but hope that Kristof or you
can come up with a refined patch :)

Re: [PATCH] postfix won't build on FREEBSD 7.2+

[Sahil Tandon]

On Sun, 2011-02-27 at 20:44:36 +0100, Matthias Andree wrote:

> Am 27.02.2011 20:41, schrieb Sahil Tandon:
> > On Sun, 2011-02-27 at 18:33:39 +0100, Matthias Andree wrote:
> > 
> >> Am 26.02.2011 00:52, schrieb Sahil Tandon:
> >>> On Fri, 2011-02-25 at 10:50:45 +0100, kristof.vans...@telenet.be wrote:
> >>>
>  This problem exist in the 2.7 and 2.8 branch: 
> 
>  In file included from attr_clnt.c:77: 
>  /usr/include/unistd.h:329: error: conflicting types for 'closefrom' 
>  ./sys_defs.h:1399: error: previous declaration of 'closefrom' was here 
>  *** Error code 1 
> 
>  Stop in /home/src/postfix-2.7.2/src/util. 
>  *** Error code 1 
> 
>  Stop in /home/src/postfix-2.7.2. 
> >>>
> >>> Ah, you are not using the ports infrastructure, in which sys_defs.h has
> >>> been patched to be aware of the closefrom() system call in 702104 and
> >>> other FreeBSD versions.
> >>>
> >>> FWIW, this issue was discussed[1] on -devel a few months ago.
> >>
> >> Maybe, but pulling the patch into the upstream sources would seem right
> >> to put this refinement where it belongs, no?
> > 
> > I do not understand your response.  "Maybe" what?  The patch for
> > upstream has already been proposed in the link I pasted earlier in this
> > thread.  So, naturally, I agree that upstream is the correct place for
> > this "refinement".  When some iteration of it is incorporated by Wietse,
> > we'll just remove it from ports.
> 
> Yeah.  The simplest thing would be ditching FreeBSD 7.1 support (FreeBSD
> 7.1 will be discontinued after tomorrow).

Agreed; but for the record, the patch we use in ports does not break the
build on my RELENG_7_1 virtual machine.

-- 
Sahil Tandon 

Re: Postfix/Upstart, the final conclusion

[Daniel Bromberg]

On 2/27/2011 1:10 PM, Reindl Harald wrote:

Thank you for your informations and very good documentation!

Has anybody an eye to systemd/postfix because systemd will
replace sysvinit/upstart in the upcoming Fedora 16 and
so also in future RHEL-Versions and maybe replace
upstart/sysvinit sooner or later in other distributions
because the design of systemd seems to be really good

Am 27.02.2011 19:01, schrieb Wietse Venema:
systemd seems much more well thought out and has a genuine service model 
that captures (among other things) dependencies, resource quotas, 
parallelization, lazy evaluation, and event registration. apparently, it 
has a great deal in common with the similarly well-designed Apple 
launchd, despite the fact than earlier poster showed that Apple violated 
the startup API of postfix. anyway, i reproduce here for consideration, 
though, the recommended daemon guidelines. not being familiar with 
postfix startup code but only reading the recent posts, it seems systemd 
compatibility would pose similar (and more?) problems that are posed 
with upstart. also, it quite clearly states it is *very* Linux specific 
which leaves a source tree creaking and clunking towards multiple 
diverse targets with contortions well beyond an #ifdef pair. well, i 
just put this out here to share my research.


http://0pointer.de/blog/projects/systemd.html


   Writing Daemons

An ideal daemon for use with systemd does a few things differently then 
things were traditionally done. Later on, we will publish a longer guide 
explaining and suggesting how to write a daemon for use with this 
systemd. Basically, things get simpler for daemon developers:


   * We ask daemon writers not to fork or even double fork in their
 processes, but run their event loop from the initial process
 systemd starts for you. Also, don't call setsid().
   * Don't drop user privileges in the daemon itself, leave this to
 systemd and configure it in systemd service configuration files.
 (There are exceptions here. For example, for some daemons there
 are good reasons to drop privileges inside the daemon code, after
 an initialization phase that requires elevated privileges.)
   * Don't write PID files
   * Grab a name on the bus
   * You may rely on systemd for logging, you are welcome to log
 whatever you need to log to stderr.
   * Let systemd create and watch sockets for you, so that socket
 activation works. Hence, interpret $LISTEN_FDS and $LISTEN_PID as
 described above.
   * Use SIGTERM for requesting shut downs from your daemon.

Re: Postfix/Upstart, the final conclusion

[Jeroen Geilman]

On 02/27/2011 08:34 PM, Reindl Harald wrote:

sorry that was because normally i use "reply all" what is needed
on some mailing-lists which are sending the message with "from"
as the users address and if you use there "reply" only nobody on
the list will ever see a message
   


That is normal behaviour, at least for this list.
Your message has these address headers:

From: Reindl Harald 
To: postfix-users@postfix.org
Sender: owner-postfix-us...@postfix.org
List-Post: 

Any modern MUA will understand and respect what they mean and what they 
should be used for.
I use Thunderbird 3, which has a context-sensitive "Reply to List" 
button; i.e. it only appears when there is a list address to use.


Blindly using the header From: address will NOT result in a proper list 
submission.



--
J.

Re: Postfix/Upstart, the final conclusion

[Reindl Harald]

Am 27.02.2011 21:55, schrieb Jeroen Geilman:
> On 02/27/2011 08:34 PM, Reindl Harald wrote:
>> sorry that was because normally i use "reply all" what is needed
>> on some mailing-lists which are sending the message with "from"
>> as the users address and if you use there "reply" only nobody on
>> the list will ever see a message
>>
> 
> That is normal behaviour, at least for this list.
> Your message has these address headers:
> 
> From: Reindl Harald 
> To: postfix-users@postfix.org
> Sender: owner-postfix-us...@postfix.org
> List-Post: 
> 
> Any modern MUA will understand and respect what they mean and what they 
> should be used for
> I use Thunderbird 3, which has a context-sensitive "Reply to List" 
> button; i.e. it only appears when there is a list address to use.

and if the MUA would really respect it would work with the normal reply-button
instead of looking at every single mail and using the right function

so you could make a bugreport for thunderbird
but this is really off-topic here



signature.asc
Description: OpenPGP digital signature

Re: [PATCH] postfix won't build on FREEBSD 7.2+

[Wietse Venema]

Sahil Tandon:
> > Yeah.  The simplest thing would be ditching FreeBSD 7.1 support (FreeBSD
> > 7.1 will be discontinued after tomorrow).
> 
> Agreed; but for the record, the patch we use in ports does not break the
> build on my RELENG_7_1 virtual machine.

I have verified that the patch does not break the build on my
FreeBSD 7.1 and 7.2 test machines. It is adopted now.

By the way, closefrom() does not seem to have a manpage before
FreeBSD 7.3, and that manpage says "The closefrom() function first
appeared in FreeBSD 8.0". Come on, people.

Wietse

test submission on 587

[jeffrey j donovan]

greetings
how can i test submission to port 587 from command line ?

I am  setting up a relay for my some users to use when they are off site. Those 
that have verizon need to use 587
I want to watch each step through so that i can make sure I have a clean path.

-j

Re: test submission on 587

[Wietse Venema]

jeffrey j donovan:
> greetings
> how can i test submission to port 587 from command line ?
> 
> I am  setting up a relay for my some users to use when they are off site. 
> Those that have verizon need to use 587
> I want to watch each step through so that i can make sure I have a clean path.

If the port requires TLS:

$ openssl s_client -quiet -starttls smtp -connect host:587
helo client.example.com
mail from:
etc. 

Otherwise:

$ telnet host 587
helo client.example.com
mail from:
etc. 

Wietse

Re: test submission on 587

[Noel Jones]

On 2/27/2011 3:21 PM, jeffrey j donovan wrote:

greetings
how can i test submission to port 587 from command line ?


# telnet localhost 587
if you get a greeting from postfix, then postfix is listening. 
 Good.


If you require STARTTLS encryption, you can test that with
# openssl s_client -connect localhost:587 -starttls smtp
Again, if you get a postfix prompt (after a couple pages of 
TLS negotiation), good.


Openssl s_client is not a suitable tool for testing an entire 
mail transaction.  If the first two steps work, setup your 
favorite mail client and give it a whirl.


It's also customary to listen on port 465/smtps with TLS 
wrappermode enabled for those clients that prefer that 
interface.  Test that port with

# openssl s_client -connect localhost:465
(telnet doesn't speak tls wrappermode)

I also find it *very* helpful to add a custom syslog name in 
master.cf so you can tell which service a client is connected 
to. eg.

# master.cf
submission ... smtpd
... your settings ...
  -o syslog_name=postfix-submission

smtps ... smtpd
... your settings ...
  -o syslog_name=postfix-smtps



  -- Noel Jones



I am  setting up a relay for my some users to use when they are off site. Those 
that have verizon need to use 587
I want to watch each step through so that i can make sure I have a clean path.

-j

Re: test submission on 587

[Patrick Ben Koetter]

* jeffrey j donovan :
> greetings
> how can i test submission to port 587 from command line ?
> 
> I am  setting up a relay for my some users to use when they are off site.
> Those that have verizon need to use 587 I want to watch each step through so
> that i can make sure I have a clean path.

If you need to use TLS, use "openssl s_client..." to start the TLS session.
See  for an intro into using the
s_client.

Then use gen-auth  to generate a AUTH
string that works with your mechanisms.

p@rick

-- 
All technical questions asked privately will be automatically answered on the
list and archived for public access unless privacy is explicitely required and
justified.

saslfinger (debugging SMTP AUTH):

Re: test submission on 587

[Wietse Venema]

Wietse Venema:
> jeffrey j donovan:
> > greetings
> > how can i test submission to port 587 from command line ?
> > 
> > I am  setting up a relay for my some users to use when they are off site. 
> > Those that have verizon need to use 587
> > I want to watch each step through so that i can make sure I have a clean 
> > path.
> 
> If the port requires TLS:
> 
> $ openssl s_client -quiet -starttls smtp -connect host:587
> helo client.example.com
> mail from:

Caution: s_client uses R and Q for itself, so send lower case commands
(rcpt to and quit).

Wietse
> 
> Otherwise:
> 
> $ telnet host 587
> helo client.example.com
> mail from:
> etc. 
> 
>   Wietse
> 
> 

Re: test submission on 587

[Noel Jones]

On 2/27/2011 3:44 PM, Wietse Venema wrote:

Wietse Venema:

jeffrey j donovan:

greetings
how can i test submission to port 587 from command line ?

I am  setting up a relay for my some users to use when they are off site. Those 
that have verizon need to use 587
I want to watch each step through so that i can make sure I have a clean path.


If the port requires TLS:

$ openssl s_client -quiet -starttls smtp -connect host:587
helo client.example.com
mail from:


Caution: s_client uses R and Q for itself, so send lower case commands
(rcpt to and quit).

Wietse


I believe "r" and "q" are reserved also.  Attempting a full 
mail transaction with s_client will likely lead to frustration 
and may lead one to waste time solving problems that don't exist.


If the connection works enough for "EHLO world" and a 
response, use a real mail client for a full test.  Once the 
connection works, very likely anything else that needs 
tweaking will show up in the postfix log.




The key actions are documented in
# man 1 s_server



  -- Noel Jones

Re: test submission on 587

[Wietse Venema]

Noel Jones:
> On 2/27/2011 3:44 PM, Wietse Venema wrote:
> > Wietse Venema:
> >> jeffrey j donovan:
> >>> greetings
> >>> how can i test submission to port 587 from command line ?
> >>>
> >>> I am  setting up a relay for my some users to use when they are off site. 
> >>> Those that have verizon need to use 587
> >>> I want to watch each step through so that i can make sure I have a clean 
> >>> path.
> >>
> >> If the port requires TLS:
> >>
> >> $ openssl s_client -quiet -starttls smtp -connect host:587
> >> helo client.example.com
> >> mail from:
> >
> > Caution: s_client uses R and Q for itself, so send lower case commands
> > (rcpt to and quit).
> >
> > Wietse
> 
> I believe "r" and "q" are reserved also.  Attempting a full 

They are not reserved on my machine.

Wietse

> mail transaction with s_client will likely lead to frustration 
> and may lead one to waste time solving problems that don't exist.
> 
> If the connection works enough for "EHLO world" and a 
> response, use a real mail client for a full test.  Once the 
> connection works, very likely anything else that needs 
> tweaking will show up in the postfix log.
> 
> 
> 
> The key actions are documented in
> # man 1 s_server
> 
> 
> 
>-- Noel Jones
> 
> 

Re: [PATCH] postfix won't build on FREEBSD 7.2+

[Pau Amma]

On Sun, February 27, 2011 9:14 pm, Wietse Venema wrote:
> By the way, closefrom() does not seem to have a manpage before
> FreeBSD 7.3, and that manpage says "The closefrom() function first
> appeared in FreeBSD 8.0". Come on, people.

That's correct, technically at least. (And as far as FreeBSD hiostory is
concerned.)

It appeared in (what became) 8.0. By the time
http://svn.freebsd.org/viewvc/base?view=revision&revision=194262 was
committed, 7.* branches had already been split from head.
http://svn.freebsd.org/viewvc/base?view=revision&revision=195694 then
backported to 7.(mumble)

Re: test submission on 587

[Noel Jones]

On 2/27/2011 4:04 PM, Wietse Venema wrote:

Noel Jones:

On 2/27/2011 3:44 PM, Wietse Venema wrote:

Wietse Venema:

jeffrey j donovan:

greetings
how can i test submission to port 587 from command line ?

I am  setting up a relay for my some users to use when they are off site. Those 
that have verizon need to use 587
I want to watch each step through so that i can make sure I have a clean path.


If the port requires TLS:

$ openssl s_client -quiet -starttls smtp -connect host:587
helo client.example.com
mail from:


Caution: s_client uses R and Q for itself, so send lower case commands
(rcpt to and quit).

Wietse


I believe "r" and "q" are reserved also.  Attempting a full


They are not reserved on my machine.

Wietse




I just tested it, and indeed lower-case letters worked fine 
for an smtp test.


I could have sworn that this was a problem, and the 
documentation appears to support that claim.  Oh well.



  -- Noel Jones

Re: test submission on 587

[Wietse Venema]

Noel Jones:
>  $ openssl s_client -quiet -starttls smtp -connect host:587
>  helo client.example.com
>  mail from:
> >>>
> >>> Caution: s_client uses R and Q for itself, so send lower case commands
> >>> (rcpt to and quit).
> >>>
> >>>   Wietse
> >>
> >> I believe "r" and "q" are reserved also.  Attempting a full
> >
> > They are not reserved on my machine.
> 
> I just tested it, and indeed lower-case letters worked fine 
> for an smtp test.
> 
> I could have sworn that this was a problem, and the 
> documentation appears to support that claim.  Oh well.

What tipped me off was that the documentation said R and Q. Taking
documentation literally as I usually do :-), I then confirmed that
lowercase input indeed works as documented.

Wietse

Re: test submission on 587

[Noel Jones]

On 2/27/2011 4:33 PM, Wietse Venema wrote:

Noel Jones:

$ openssl s_client -quiet -starttls smtp -connect host:587
helo client.example.com
mail from:


Caution: s_client uses R and Q for itself, so send lower case commands
(rcpt to and quit).

Wietse


I believe "r" and "q" are reserved also.  Attempting a full


They are not reserved on my machine.


I just tested it, and indeed lower-case letters worked fine
for an smtp test.

I could have sworn that this was a problem, and the
documentation appears to support that claim.  Oh well.


What tipped me off was that the documentation said R and Q. Taking
documentation literally as I usually do :-), I then confirmed that
lowercase input indeed works as documented.

Wietse


Perhaps surprisingly, same here.  The docs I checked for 
s_client listed no magic keys and referred me to s_server; the 
s_server docs clearly stated that [QqRrPS] have special meaning.


But I think we can drop this now.

  -- Noel Jones

Re: Postfix/Upstart, the final conclusion

[Victor Duchovni]

On Sun, Feb 27, 2011 at 07:10:09PM +0100, Reindl Harald wrote:

> Thank you for your informations and very good documentation!
> 
> Has anybody an eye to systemd/postfix because systemd will
> replace sysvinit/upstart in the upcoming Fedora 16 and
> so also in future RHEL-Versions and maybe replace
> upstart/sysvinit sooner or later in other distributions
> because the design of systemd seems to be really good

Postfix is not a simple daemon processing requests from a single socket.
The master.cf file specifies multiple services, some may be temporarily
disabled via "master_service_disable", ... On top of that there can
be multiple Postfix instances.

What this means is that Postfix  needs to run when the system is started,
and stop when the system is stopped. Attempting to tie this to network
or file-system events is unwise except perhaps in the most trivial
deployments (null-client laptop), where Postfix may well be the wrong
choice of MTA. [ It is cute that Postfix code I contributed is included
on my MacBook, but I never use it, I use Apple's MUA, configured to send
to a real Postfix port 587 submission service. ]

Integration with systemd (which does appear better designed than upstart)
is I think easier than with upstart. Postfix can continue to be a classic
LSB init.d service. It looks no changes to Postfix are required to support
systemd.

-- 
Viktor.