Re: Small Enhancement Request

2014-10-09 Thread Emmanuel Fusté

Le 09/10/2014 07:43, Ronald F. Guilmette a écrit :

This is a request for a very minor change to the semantics of the
PREPEND text result that can be returned from policy servers
and/or from specific entries within an access(5) lookup table.

It would be maximally convenient if the subject text could be
interpolated in the following trivial way:

  Any literal \n (backslash-n) sequence withing text is
  replaced with an actual newline character.

This trivial change would allow prepending of multiple headers
to the current e-mail message.

This capability would be useful in the context of systems that
tag incoming messages for later analysis and/or special processing
by tools external to the mail server.

Alternatively, given that the Postfix policy server protocol
theoretically allows for the possibility of a policy server
yielding multiple action=PREPEND text results in response
to any given single request (from Postfix), it would be Nice if
Postfix would in fact accept a sequence of multiple such responses
from a policy server in response to a single request.

Hello,

Do you tried multiple PREPEND result for the same pattern in an access 
table (or a table for each header to PREPEND)?
As the PREPEND action does not accept or reject the message, it 
should be view as a DUNNO action for the evaluation of the access rule.


Emmanuel.


Re: Another policy server question...

2014-10-09 Thread Jan P. Kessler



How exactly does one disconnect from stdin?  I mean other than by
calling exit() ?


Exiting is sufficient.


The SMTPD_POLICY_README file should be edited in a way so as to
make that clear.  The current wording is quite entirely perplexing.
Disconnect is quite obviously the wrong word to use in this
context.


No, the wording is correct. Spawn(8) is only one way to create a policy 
service. If you decide to write your own daemon with own socket code, 
you will have to close the connection.




Re: Small Enhancement Request

2014-10-09 Thread Wietse Venema
Ronald F. Guilmette:
 
 This is a request for a very minor change to the semantics of the
 PREPEND text result that can be returned from policy servers
 and/or from specific entries within an access(5) lookup table.
 
 It would be maximally convenient if the subject text could be
 interpolated in the following trivial way:
 
  Any literal \n (backslash-n) sequence withing text is
  replaced with an actual newline character.

Sorry, I do not support ASCII art. If you have something
to say, make it a one-liner.

Wietse


Re: Policy Server (action=PREPEND text) Questions (redux)

2014-10-09 Thread Viktor Dukhovni
On Wed, Oct 08, 2014 at 11:53:57PM -0500, Noel Jones wrote:

  That delay, in and of itself is not really a problem for me.  What
  _is_ a bit of a problem is the fact that smtpd_delay_reject doesn't
  merely cause anything listed under smtpd_sender_restrictions to be
  delayed until such time as the _first_ RCPT TO is seen, but rather
  it causes each of the things listed under smtpd_sender_restrictions
  to be reevaluated, once for each RCPT TO. 
 
 Yes, this is an implementation artifact.  I don't know if it's worth
 fixing since it rarely causes an issue.

Actually, it is a design feature.  It allows those restriction
classes to also look at the recipient.  There is nothing to fix.

Long ago I proposed generalizing the model to allow users to specify
a list of top-level restriction classes that apply to each protocol
stage.  Wietse adopted just smtpd_relay_restrictions, and deemed
the rest needlessly complex, but the basic design is that whatever
set of restriction classes apply to the first recipient at RCPT TO
time also apply equally to the rest.

-- 
Viktor.


Re: Policy Server (action=PREPEND text) Questions (redux)

2014-10-09 Thread Viktor Dukhovni
On Wed, Oct 08, 2014 at 10:25:11PM -0700, Ronald F. Guilmette wrote:

 Thank you very much!  I believe that will solve the multiple evaluation
 problem for me.  And I guess that executing my policy server as part of
 smtpd_data_restrictions will also allow me to turn back on the
 smtpd_delay_reject setting... which I had turned off, for the time
 being, in order to avoid the multiple evaluation problem.

Note at the data stage the recipient is not available when there
is more than one.  Some sophisticated policy servers are called for
each recipient and return DUNNO, using those calls to collect the
message envelope, and then are called again at DATA and return the
final action.

-- 
Viktor.


Re: Another policy server question...

2014-10-09 Thread Viktor Dukhovni
On Wed, Oct 08, 2014 at 06:17:45PM -0700, Ronald F. Guilmette wrote:

 The SMTPD_POLICY_README file says:
 
 In case of trouble the policy server must not send a reply. Instead the 
 server
 must log a warning and disconnect. Postfix will retry the request at some 
 later
 time.
 
 
 Ummm...
 
 I can easly handle the log a warning part, but...
 
 As I understand it, a Postfix policy server is supposed to be reading
 incoming requests from stdin.

No, it is supposed to be accepting requests via TCP or unix domain
socket.  It can even handle multiple connections via a threaded or
event based model.

 How exactly does one disconnect from stdin?  I mean other than by
 calling exit() ?

One can close a file descriptor.  However, when created by spawn(8)
the process handles just one connection, so there is nothing left
to do after closing the connection but exit().  Since exit() also
closes all files, that's enough.  In particular such a server must[
also exit when a read of stdin reports EOF.

For servers not created by spawn(8), other strategies are applicable.

-- 
Viktor.


Re: Small Enhancement Request

2014-10-09 Thread Ronald F. Guilmette

In message 3jd99m4nwtzj...@spike.porcupine.org, 
wie...@porcupine.org (Wietse Venema) wrote:

Ronald F. Guilmette:
 
 This is a request for a very minor change to the semantics of the
 PREPEND text result that can be returned from policy servers
 and/or from specific entries within an access(5) lookup table.
 
 It would be maximally convenient if the subject text could be
 interpolated in the following trivial way:
 
  Any literal \n (backslash-n) sequence withing text is
  replaced with an actual newline character.

Sorry, I do not support ASCII art. If you have something
to say, make it a one-liner.

Given that I appear to have no real choice in the matter, I shall
endeavor to do so.


Re: Small Enhancement Request

2014-10-09 Thread Ronald F. Guilmette

In message 32139_1412843719_543648c7_32139_3580_1_543648c6.9050...@external.th
alesgroup.com, =?windows-1252?Q?Emmanuel_Fust=E9?= 
emmanuel.fu...@external.thalesgroup.com wrote:

Le 09/10/2014 07:43, Ronald F. Guilmette a =E9crit :

Do you tried multiple PREPEND result for the same pattern in an access
table (or a table for each header to PREPEND)?

If I was merely using access(5) tables, I would do so, however I am
not using such tables in this instance.  Rather, I am writing a
policy server.



Re: Policy Server (action=PREPEND text) Questions (redux)

2014-10-09 Thread Ronald F. Guilmette

In message 20141009141819.go13...@mournblade.imrryr.org, 
Viktor Dukhovni postfix-us...@dukhovni.org wrote:

On Wed, Oct 08, 2014 at 10:25:11PM -0700, Ronald F. Guilmette wrote:

 Thank you very much!  I believe that will solve the multiple evaluation
 problem for me.  And I guess that executing my policy server as part of
 smtpd_data_restrictions will also allow me to turn back on the
 smtpd_delay_reject setting... which I had turned off, for the time
 being, in order to avoid the multiple evaluation problem.

Note at the data stage the recipient is not available when there
is more than one.

Thank you.  I undertand.  For me this is not an issue, as my only goal
is to perform some action (either tagging or rejection) based entirely
and strictly only upon characteristics relating to the {E}SMTP client.
The identities of individual local recipients are not relevant to what
I want to do.



Re: Small Enhancement Request

2014-10-09 Thread Viktor Dukhovni
On Thu, Oct 09, 2014 at 09:29:41AM -0700, Ronald F. Guilmette wrote:
 
 In message 
 32139_1412843719_543648c7_32139_3580_1_543648c6.9050...@external.th
 alesgroup.com, =?windows-1252?Q?Emmanuel_Fust=E9?= 
 emmanuel.fu...@external.thalesgroup.com wrote:
 
 Le 09/10/2014 07:43, Ronald F. Guilmette a =E9crit :
 
 Do you tried multiple PREPEND result for the same pattern in an access
 table (or a table for each header to PREPEND)?
 
 If I was merely using access(5) tables, I would do so, however I am
 not using such tables in this instance.  Rather, I am writing a
 policy server.

Policy services are just fancy access tables.  That's how they work
in restriction classes, which are just lists of things that all
look like access tables.

Policy servers have a much richer input syntax, but are at present
confined to the same output options as all other restriction building
blocks.

-- 
Viktor.


Re: Another policy server question...

2014-10-09 Thread Ronald F. Guilmette

In message 20141009152227.gq13...@mournblade.imrryr.org, 
Viktor Dukhovni postfix-us...@dukhovni.org wrote:

On Wed, Oct 08, 2014 at 06:17:45PM -0700, Ronald F. Guilmette wrote:
 As I understand it, a Postfix policy server is supposed to be reading
 incoming requests from stdin.

No, it is supposed to be accepting requests via TCP or unix domain
socket.  It can even handle multiple connections via a threaded or
event based model.

Please do correct me if I'm wrong... I may be misunderstanding...
but these additional possibilities you are describing would be
available _only_ if the policy server is invoked by something
other than spawn(8), correct?

I wonder how many Postfix policy servers have been written to be
invoked other than via spawn(8).  I have trouble imagining that any
have been, since just allowing them to be invoked by spawn(8)...
which automagically handles hooking up stdin to the proper socket...
is so marvelously convenient.

 How exactly does one disconnect from stdin?  I mean other than by
 calling exit() ?

One can close a file descriptor.

Well, yes, that _did_ occur to me.  However within the context of the
SMTPD_POLICY_README comment I cited, I was not and am not persuaded
that that makes a lot of sense.  Here is a more complete quote:

 In case of trouble the policy server must not send a reply. Instead
 the server must log a warning and disconnect. Postfix will retry
 the request at some later time.

If an ``ordinary'' policy server, i.e. one that is invoked by spawn(8),
disconnects by closing its stdin, then how exactly will Postfix be
able to retry the request at some later time?

Perhaps more to the point, if a given running instance of a policy server
were indeed to close its stdin _without_ exiting, of what use would it
be thereafter?  It's not as if stdin could be somehow re-opened once
the trouble has passed.

However, when created by spawn(8)
the process handles just one connection, so there is nothing left
to do after closing the connection but exit().

Exactly my point.

Since exit() also
closes all files, that's enough.  In particular such a server must
also exit when a read of stdin reports EOF.

I'm glad you mentioned that, because I wanted to ask a question about
that too.

Somewhere burried in the documentation I vaguely remember seeing a
comment to the effect that Postfix will only ask a policy server to
handle 100 requests.  (I guess that this is one way of allowing for
badly written policy servers that have, for example, memork leaks
or other kinds of problems that would otherwise build up over time.)

My question is just this:  After Postfix has sent 100 requests to a
given running instance of a policy server, and after it has successfully
received back 100 properly formatted replies from the given policy
server instance, then what happens?

My intutive guess is that then Postfix sends an EOF to the policy 
server to let it know that its tme for it to commit suicide.  However
that is just an intutive guess on my part.  Perhaps Postfix sends a
signal instead (?)

And, ah, while we are on _that_ subject, are there reccomendations
about what sorts of signals policy servers might likely receive and/or
about which ones they should attempt to catch and/or about what actions
they should try to take in response to various signals?

Since the one that I'm building will (so far) not be modifying any
files or data bases, or updating any oher kind of external state
information, I guess it's fine if it just _does not_ catch any
signals at all, and just dies ``normally'' in response to, for example,
the SIGTERM that might likely be sent to it at system shutdown time.



Re: Another policy server question...

2014-10-09 Thread li...@rhsoft.net


Am 09.10.2014 um 19:07 schrieb Ronald F. Guilmette:

I wonder how many Postfix policy servers have been written to be
invoked other than via spawn(8).  I have trouble imagining that any
have been, since just allowing them to be invoked by spawn(8)...
which automagically handles hooking up stdin to the proper socket...
is so marvelously convenient


https://github.com/jnorell/dbmail-postfix-policyd


Re: Another policy server question...

2014-10-09 Thread Wietse Venema
Ronald F. Guilmette:
 Somewhere burried in the documentation I vaguely remember seeing a
 comment to the effect that Postfix will only ask a policy server to
 handle 100 requests.  (I guess that this is one way of allowing for
 badly written policy servers that have, for example, memork leaks
 or other kinds of problems that would otherwise build up over time.)

That is incorrect. The text says:

On active systems a policy daemon process is used multiple
times, for up to $max_use incoming SMTP connections.

That is, UP TO $MAX_USE INCOMING SMTP CONNECTIONS, not
up to 100 policy server requests.

Please do read carefully before posting hypotheses and
non-applicable scenarios.

Wietse


Re: Another policy server question...

2014-10-09 Thread Viktor Dukhovni
On Thu, Oct 09, 2014 at 10:07:21AM -0700, Ronald F. Guilmette wrote:

 Please do correct me if I'm wrong... I may be misunderstanding...
 but these additional possibilities you are describing would be
 available _only_ if the policy server is invoked by something
 other than spawn(8), correct?

Yes.

 I wonder how many Postfix policy servers have been written to be
 invoked other than via spawn(8).  I have trouble imagining that any
 have been, since just allowing them to be invoked by spawn(8)...
 which automagically handles hooking up stdin to the proper socket...
 is so marvelously convenient.

Simple interfaces for sites that don't need high performance or
shared state across multiple connections.  I've written policy
services that are not spawn based.  I don't have a deployment survey
handy.

 If an ``ordinary'' policy server, i.e. one that is invoked by spawn(8),
 disconnects by closing its stdin, then how exactly will Postfix be
 able to retry the request at some later time?

Spawn launches a new process for each new connection.  If processes
launched by spawn don't exit after closing a connection, you
eventually run out of memory for processes.  Common sense applies.

 Perhaps more to the point, if a given running instance of a policy server
 were indeed to close its stdin _without_ exiting, of what use would it
 be thereafter?  It's not as if stdin could be somehow re-opened once
 the trouble has passed.

You've deduced out how to apply the logic to spawn(8) managed
processes.  It is expected that others can do likewise.

 Somewhere burried in the documentation I vaguely remember seeing a
 comment to the effect that Postfix will only ask a policy server to
 handle 100 requests.  (I guess that this is one way of allowing for
 badly written policy servers that have, for example, memork leaks
 or other kinds of problems that would otherwise build up over time.)

A policy server connection never outlives the smtpd(8) process that
is its client.  The number of requests depends on max_use, the
number of requests per mail transaction (per RCPT requests for
example) and the number transactions per connection.  There is no
default absolute ceiling.  The 100 is just an approximation.

 My question is just this:  After Postfix has sent 100 requests to a
 given running instance of a policy server, and after it has successfully
 received back 100 properly formatted replies from the given policy
 server instance, then what happens?

The answer is obvious.  If there is an explicit request limit set,
then the client disconnects, and the policy service sees EOF.

 My intutive guess is that then Postfix sends an EOF to the policy 
 server to let it know that its tme for it to commit suicide.  However
 that is just an intutive guess on my part.  Perhaps Postfix sends a
 signal instead (?)

The simplest and clearly correct approach is to disconnect.

 And, ah, while we are on _that_ subject, are there reccomendations
 about what sorts of signals policy servers might likely receive and/or
 about which ones they should attempt to catch and/or about what actions
 they should try to take in response to various signals?

Don't let your imagination carry you away...

 Since the one that I'm building will (so far) not be modifying any
 files or data bases, or updating any oher kind of external state
 information, I guess it's fine if it just _does not_ catch any
 signals at all, and just dies ``normally'' in response to, for example,
 the SIGTERM that might likely be sent to it at system shutdown time.

There you go, common sense.

-- 
Viktor.


Re: Small Enhancement Request

2014-10-09 Thread Ronald F. Guilmette

In message 20141009163728.gt13...@mournblade.imrryr.org, 
Viktor Dukhovni postfix-us...@dukhovni.org wrote:

On Thu, Oct 09, 2014 at 09:29:41AM -0700, Ronald F. Guilmette wrote:
 
 In message 32139_1412843719_543648C7_32139_3580_1_543648C6.9050308@external
.th
 alesgroup.com, =?windows-1252?Q?Emmanuel_Fust=E9?= emmanuel.fuste@external
.thalesgroup.com wrote:
 
 Le 09/10/2014 07:43, Ronald F. Guilmette a =E9crit :
 
 Do you tried multiple PREPEND result for the same pattern in an access
 table (or a table for each header to PREPEND)?
 
 If I was merely using access(5) tables, I would do so, however I am
 not using such tables in this instance.  Rather, I am writing a
 policy server.

Policy services are just fancy access tables.  That's how they work
in restriction classes, which are just lists of things that all
look like access tables.

Hummm... well now, your comment, together with the one made by Emmanuel
Fust, are causing me to wonder if I may have been harboring a profound
misunderstanding of access tables.

What happens if in fact the matching rules specified in the access(5)
man page resulted in matching _multiple_ things at the same priority/
precedence level?  For example, what if I had the following table:

domain.tld  PREPEND X-Foo: bar
domain.tld  PREPEND X-Bar: for

(This seems to be the exact kind of thing that Emmanuel Fust was
suggesting that I try.  However I have a dim recollection that
long long ago I messed up some of my local blacklists in this
exact way, i.e. by having multiple keys, each associated with
different values, and when I tried to compile said lists,
postmap complained... as seemed entirely reasonable... about the
presence of duplicate keys.)


Re: Another policy server question...

2014-10-09 Thread Ronald F. Guilmette

In message 3jdjvm2k00zj...@spike.porcupine.org, 
wie...@porcupine.org (Wietse Venema) wrote:

Ronald F. Guilmette:
 Somewhere burried in the documentation I vaguely remember seeing a
 comment to the effect that Postfix will only ask a policy server to
 handle 100 requests.  (I guess that this is one way of allowing for
 badly written policy servers that have, for example, memork leaks
 or other kinds of problems that would otherwise build up over time.)

That is incorrect. The text says:

On active systems a policy daemon process is used multiple
times, for up to $max_use incoming SMTP connections.

That is, UP TO $MAX_USE INCOMING SMTP CONNECTIONS, not
up to 100 policy server requests.

Please do read carefully before posting hypotheses and
non-applicable scenarios.

OK, I'm reading (and re-reading, and re-re-reading) the statement in
question, which appears in the SMTPD_POLICY_README, and I'm sorry to
say that I still find it almost imponderably ambiguous.

Please clarify your use of the word use in this context.  What does
it mean for a policy daemon to be used?  If something sends a
single request to a policy daemon, and it receives back a properly
formatted response from the daemon, isn't that a use of the
daemon?  In what sense is such a single transaction _not_ a use of
the daemon?

Perhaps you and I are working from different dictionaries, but where
I come from a _single_ such transaction would be considered a use
of the daemon.  I believe that the vast majority of native English
speakers would agree.

If you went and obtained cash out of your local ATM 100 times last
year, then how many times did you use that ATM last year?  Once??

If I have failed to grasp that fact that you had some obscure and
non-standard meaning in mind for the word use in this context,
then I do apologize.  I shall in future try harder to intuit your
intended meanings, even when ordinary everyday English usage would
suggest other and more obvious interpretations.

In any event, regardless of how this key sentence is construed, it
self-evidently leaves open a rather obvious quetion:  What happens,
exactly, when the $max_use limit is exceeded?  The document makes
no effort at all to specify, leaving the reader to wonder why this
limit was even mentioned at all.

It's like as if I I told my friend that I would use my local ATM
up to 100 times this year.

My friend might then reasonably ask:  Yea, and THEN what?

I now ask the analogous question:  What happens after $max_use ?

It seems a reasonable question.  The document does not provide an
answer.


Re: Another policy server question...

2014-10-09 Thread Wietse Venema
Ronald F. Guilmette:
 
 In message 3jdjvm2k00zj...@spike.porcupine.org, 
 wie...@porcupine.org (Wietse Venema) wrote:
 
 Ronald F. Guilmette:
  Somewhere burried in the documentation I vaguely remember seeing a
  comment to the effect that Postfix will only ask a policy server to
  handle 100 requests.  (I guess that this is one way of allowing for
  badly written policy servers that have, for example, memork leaks
  or other kinds of problems that would otherwise build up over time.)
 
 That is incorrect. The text says:
 
 On active systems a policy daemon process is used multiple
 times, for up to $max_use incoming SMTP connections.
 
 That is, UP TO $MAX_USE INCOMING SMTP CONNECTIONS, not
 up to 100 policy server requests.
 
 Please do read carefully before posting hypotheses and
 non-applicable scenarios.
 
 OK, I'm reading (and re-reading, and re-re-reading) the statement in
 question, which appears in the SMTPD_POLICY_README, and I'm sorry to
 say that I still find it almost imponderably ambiguous.
 
 Please clarify your use of the word use in this context.  What does
 it mean for a policy daemon to be used?  If something sends a

Sorry, I am not going to explain how client-server architecture
works. This is assumed knowledge for the Postfix documentation
audience. Client-server was a hot topic 30+ years ago.

Wietse


Re: Another policy server question...

2014-10-09 Thread Ronald F. Guilmette

In message 20141009172354.gu13...@mournblade.imrryr.org, 
Viktor Dukhovni postfix-us...@dukhovni.org wrote:

Spawn launches a new {policy} process for each new {SMTP} connection.

Thank you!  I most certainly did not grasp that until just this moment.

A policy server connection never outlives the smtpd(8) process that
is its client.

I wish that both of the above statements and/or the general concept
of the one-to-one correlation between running policy daemon instances
and incoming SMTP sessions had been noted at the very top of the
SMTPD_POLICY_README document.

That would have prevented a lot of confusion on my part.

The number of requests depends on max_use, the
number of requests per mail transaction (per RCPT requests for
example) and the number transactions per connection.  There is no
default absolute ceiling.  The 100 is just an approximation.

 My question is just this:  After Postfix has sent 100 requests to a
 given running instance of a policy server, and after it has successfully
 received back 100 properly formatted replies from the given policy
 server instance, then what happens?

The answer is obvious.  If there is an explicit request limit set,
then the client disconnects, and the policy service sees EOF.

I think that you just utterly negated what Wietse just got done telling
me, i.e. that $max_use and the number of individual requests sent to a
given policy server are not at all related to one another.

Did I misconstrue him, or have I instead misconstrued you?

Is $max_use a limit that applies to the count of individual policy
server *requests* or not?


Re: Another policy server question...

2014-10-09 Thread Ronald F. Guilmette

In message 3jdlhr1bzjzj...@spike.porcupine.org, you wrote:

Ronald F. Guilmette:
 OK, I'm reading (and re-reading, and re-re-reading) the statement in
 question, which appears in the SMTPD_POLICY_README, and I'm sorry to
 say that I still find it almost imponderably ambiguous.
 
 Please clarify your use of the word use in this context.  What does
 it mean for a policy daemon to be used?  If something sends a

Sorry, I am not going to explain how client-server architecture
works.

I didn't ask you to, nor do I need you to.  I have a firm grasp of
those concepts.

I'm asking you to explain your documentation, and specifically why
you have a different understanding of the word use that the vast
majority of other people fluent in the English language, and why
you elect to blame the readers of said documentation for not
immediately grasping that what you wrote was not in fact what you
meant.



Re: Another policy server question...

2014-10-09 Thread Wietse Venema
Ronald F. Guilmette:
 
 In message 3jdlhr1bzjzj...@spike.porcupine.org, you wrote:
 
 Ronald F. Guilmette:
  OK, I'm reading (and re-reading, and re-re-reading) the statement in
  question, which appears in the SMTPD_POLICY_README, and I'm sorry to
  say that I still find it almost imponderably ambiguous.
  
  Please clarify your use of the word use in this context.  What does
  it mean for a policy daemon to be used?  If something sends a
 
 Sorry, I am not going to explain how client-server architecture
 works.
 
 I didn't ask you to, nor do I need you to.  I have a firm grasp of
 those concepts.
 
 I'm asking you to explain your documentation, and specifically why
 you have a different understanding of the word use that the vast

See http://en.wikipedia.org/wiki/Client-server_model for how a
client can use [a] server's resources. That is a direct quote.

Wietse


Re: Another policy server question...

2014-10-09 Thread Ronald F. Guilmette

In message 3jdmll1j7pzj...@spike.porcupine.org, 
wie...@porcupine.org (Wietse Venema) wrote:

Ronald F. Guilmette:
 I'm asking you to explain your documentation, and specifically why
 you have a different understanding of the word use that the vast

See http://en.wikipedia.org/wiki/Client-server_model for how a
client can use [a] server's resources. That is a direct quote.

Just repeating yourself doesn't add either any additional weight
nor any additional credibility to your argument.

I know what a client is. I know what a server is.  I have written
both kinds of software, from scratch, in C (and other languages)
multiple times.  If you are attempting to make the point that
SMTPD_POLICY_README is 100% crystal clear, either to everybody in
the known universe, or even just to a majority of those fluent
in English language, then attempting to dismiss or minimize my
experience or knowledge does not make that point for you.

As someone who has worked for a long while with SMTP, you of all
people should know that communication is a two way street, requiring
common understanding between sender and receiver.  You should know
also that documentation... English language documentation... is an
attempt to communicate... in English.  If you are using a different
dictionary than everybody else you will fail at that attempt, and
in that case why bother writing ``documentation'' at all?

No one sensible would dispute your skill as a software developer,
but I'll put my own understanding of the English language up against
your's, in a fair fight, with neutral judges, any day of the week
and twice on Sunday.

   http://www.merriam-webster.com/dictionary/use


If you write sentences that can be (and have been) misconstrued,
then yes, you can always blame the reader(s).  That's the easy way
out.


Re: Another policy server question...

2014-10-09 Thread Wietse Venema
Ronald F. Guilmette:
http://www.merriam-webster.com/dictionary/use

http://en.wikipedia.org/wiki/Plonk

Wietse


compatibility level 2 changes

2014-10-09 Thread Wietse Venema
I just implemented two more compatibility breaks with
postfix-2.12-20141009.  These are expected to be the last ones
before the Postfix 2.12 stable release (or whatever it will be
called).

- relay_domains default is changed from $mydestination to  (empty).

- mynetworks_style default is changed from subnet to host.

In both cases the backwards-compatibility safety net turns on the
old default settings, and logs what, if anything, depends on those
old defaults. Examples of messages:

postfix/smtpd[19052]: using backwards-compatible default setting
relay_domains=$mydestination to accept mail for domain
foo.example.com

postfix/smtpd[17375]: using backwards-compatible default setting
mynetworks_style=subnet to permit request from client
foo.example.com[10.1.1.1]

postfix/postscreen[24982]: using backwards-compatible default
setting mynetworks_style=subnet to permit request from client
10.1.1.1

As before, if these messages are logged for a legitimate request,
the system administrator should make the old default settings
permanent with:

# postconf parameter-name=old-default-value
# postfix reload

If the requests are not legitimate, just ignore them until you
are ready to adjust the compatibility_level setting in main.cf.

Wietse


Compiling new postfix same as the old postfix

2014-10-09 Thread LuKreme
I seem to have mislaid the note file in which I kept the build options that I 
built postfix with, and I am planning on recompiling a new version of postfix 
soon (It was supposed to be last month).

What can I look at to figure out what the build options were for the currently 
installed version so I can try to match them as closely on the new compile?


-- 
You are in my inappropriate thoughts



Re: Another policy server question...

2014-10-09 Thread LuKreme
On 09 Oct 2014, at 13:50 , Ronald F. Guilmette r...@tristatelogic.com wrote:
 No one sensible would dispute your skill as a software developer,
 but I'll put my own understanding of the English language up against
 your's,

Funniest thing all day. Hurray for Skitt’s Law.

-- 
'I thought we could do it without anyone getting hurt. By using our
brains.' 'Can't. History don't work like that. Blood first, then
brains.' 'Mountains of skulls,' said Truckle. 'There's got to be a
better way than fighting,' said Mr Saveloy. 'Yep. Lots of 'em. Only
none of 'em work.'



Re: Another policy server question...

2014-10-09 Thread Viktor Dukhovni
On Thu, Oct 09, 2014 at 11:46:24AM -0700, Ronald F. Guilmette wrote:

 Viktor Dukhovni postfix-us...@dukhovni.org wrote:
 
 Spawn launches a new {policy} process for each new {SMTP} connection.
 
 Thank you!  I most certainly did not grasp that until just this moment.

No, I deliberately did not use the words you inserted.  I said
spawn(8) creates a new process for each new connection.

Nowhere did I say that smtpd(8) makes a new policy service connection
for each SMTP client connection.

-- 
Viktor.


Re: Small Enhancement Request

2014-10-09 Thread Viktor Dukhovni
On Thu, Oct 09, 2014 at 10:28:52AM -0700, Ronald F. Guilmette wrote:

 What happens if in fact the matching rules specified in the access(5)
 man page resulted in matching _multiple_ things at the same priority/
 precedence level?  For example, what if I had the following table:
 
 domain.tldPREPEND X-Foo: bar
 domain.tldPREPEND X-Bar: for

Now you're showing a misunderstanding of Postfix tables.  They are
key-value mappings.  Single key, single value.  If you postmap(1)
such a table, there'll be only one domain.tld and a warning will
be logged about the duplicate.  If this were a regexp_table(5),
the first match wins.

With *SQL and LDAP, multiple result rows for a single lookup key
are collapsed to a single comma-separated string, which won't do
you much good since it will prepend a single mangled header:

X-Foo: bar,PREPEND X-Bar: foo

Things are rather much simpler than you imagine, and generally
pretty much as described.  It is a mistake to conjure up clever
interpretations of the text.

-- 
Viktor.


Re: Small Enhancement Request

2014-10-09 Thread Ronald F. Guilmette

In message 20141010030256.gw13...@mournblade.imrryr.org, 
Viktor Dukhovni postfix-us...@dukhovni.org wrote:

On Thu, Oct 09, 2014 at 10:28:52AM -0700, Ronald F. Guilmette wrote:

 What happens if in fact the matching rules specified in the access(5)
 man page resulted in matching _multiple_ things at the same priority/
 precedence level?  For example, what if I had the following table:
 
 domain.tld   PREPEND X-Foo: bar
 domain.tld   PREPEND X-Bar: for

Now you're showing a misunderstanding of Postfix tables.  They are
key-value mappings.

Actually, I *did* (and do) understand that point.  I was just asking
for it to be confirmed, since another poster suggested yielding
multiple values for a single lookup key, which on the face of it made
no sense to me.



Re: Another policy server question...

2014-10-09 Thread Lothar Gesslein
On 10/09/2014 08:25 PM, Ronald F. Guilmette wrote:
 In any event, regardless of how this key sentence is construed, it
 self-evidently leaves open a rather obvious quetion:  What happens,
 exactly, when the $max_use limit is exceeded?  The document makes
 no effort at all to specify, leaving the reader to wonder why this
 limit was even mentioned at all.

It is mentioned at that point only to make the reader understand that a
policy daemon will usually perform well, even if written in a slow
language with a relevant startup overhead. When there are say 10
incoming mails per second you do NOT spawn 10 ruby-processes per second,
which would be a noticeable load, but reuse one process until $max_use
is reached.

 I now ask the analogous question:  What happens after $max_use ?
 
 It seems a reasonable question.  The document does not provide an
 answer.

The process is terminated, a new process will then be spawned on the
next connection. This is nothing particular to the policy delegation,
just the way the Postfix spawn(8) daemon works. And the suggested
configuration is to have your policy service run under the control of
spawn(8).

Best regards,
Lothar

-- 
Lothar Gesslein
Linux Consultant
Mail: gessl...@b1-systems.de

B1 Systems GmbH
Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de
GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537



signature.asc
Description: OpenPGP digital signature