Re: Small Enhancement Request
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...
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
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)
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)
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...
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
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
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)
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
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...
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...
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...
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...
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
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...
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...
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...
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...
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...
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...
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...
Ronald F. Guilmette: http://www.merriam-webster.com/dictionary/use http://en.wikipedia.org/wiki/Plonk Wietse
compatibility level 2 changes
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
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...
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...
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
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
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...
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
