Re: Question about service daemon man pages
On 2021-05-22 8:05 a.m., Wietse Venema wrote: J Doe: A section that is shared in all of the service daemon man pages is "CONFIGURATION PARAMETERS". In bounce(8) there are parameters under this section that relate to delivery status notifications. For instance: delay_notice_recipient. This made me think that bounce(8) is solely responsible for DSN's. Wietse: No it's not. The bounce daemon *uses* the time to warn in notifications (your message could not be delivered for more than $delay_warning_time_hours hours). The cleanup daenon *stores* the time to warn in queue files. Additionally, the queue manager *enforces* the time to warn by requesting that a warning notification is sent. J Doe: Ok, would the more accurate takeaway be that more than one daemon can consult/consume a parameter in main.cf and the fact that a parameter is listed in a service daemon man page does _not_ mean that that one daemon "owns" the parameter ? It means that the parameter setting is *used* by the program. There are dozens of parameters that are used in more than one program. queue_directory, soft_bounce, myhostname, mail_name, line_length_limit, and many more. Wietse Hi Wietse, Ok, great - thank you for clarifying that for me. - J
Re: Question about service daemon man pages
J Doe: J Doe: > A section that is shared in all of the service daemon man pages is > "CONFIGURATION PARAMETERS". In bounce(8) there are parameters under > this section that relate to delivery status notifications. For > instance: delay_notice_recipient. This made me think that bounce(8) is > solely responsible for DSN's. Wietse: > No it's not. The bounce daemon *uses* the time to warn in notifications > (your message could not be delivered for more than > $delay_warning_time_hours hours). > > The cleanup daenon *stores* the time to warn in queue files. > > Additionally, the queue manager *enforces* the time to warn by > requesting that a warning notification is sent. J Doe: > Ok, would the more accurate takeaway be that more than one daemon can > consult/consume a parameter in main.cf and the fact that a parameter is > listed in a service daemon man page does _not_ mean that that one daemon > "owns" the parameter ? It means that the parameter setting is *used* by the program. There are dozens of parameters that are used in more than one program. queue_directory, soft_bounce, myhostname, mail_name, line_length_limit, and many more. Wietse
Re: Question about service daemon man pages
On 2021-05-21 7:34 p.m., Wietse Venema wrote: J Doe: Hello, I have a question about the man pages for the service daemons that are executed via master(8). A section that is shared in all of the service daemon man pages is "CONFIGURATION PARAMETERS". In bounce(8) there are parameters under this section that relate to delivery status notifications. For instance: delay_notice_recipient. This made me think that bounce(8) is solely responsible for DSN's. No it's not. The bounce daemon *uses* the time to warn in notifications (your message could not be delivered for more than $delay_warning_time_hours hours). When I check cleanup(8) under "CONFIGURATION PARAMETERS" I see: delay_warning_time which also relates to DSN's. The cleanup daenon *stores* the time to warn in queue files. Additionally, the queue manager *enforces* the time to warn by requesting that a warning notification is sent. Wietse Hi Wietse, Thanks for your reply. Ok, would the more accurate takeaway be that more than one daemon can consult/consume a parameter in main.cf and the fact that a parameter is listed in a service daemon man page does _not_ mean that that one daemon "owns" the parameter ? Thanks again, - J
Re: Question about service daemon man pages
J Doe: > Hello, > > I have a question about the man pages for the service daemons that are > executed via master(8). > > A section that is shared in all of the service daemon man pages is > "CONFIGURATION PARAMETERS". In bounce(8) there are parameters under > this section that relate to delivery status notifications. For > instance: delay_notice_recipient. This made me think that bounce(8) is > solely responsible for DSN's. No it's not. The bounce daemon *uses* the time to warn in notifications (your message could not be delivered for more than $delay_warning_time_hours hours). > When I check cleanup(8) under "CONFIGURATION PARAMETERS" I see: > delay_warning_time which also relates to DSN's. The cleanup daenon *stores* the time to warn in queue files. Additionally, the queue manager *enforces* the time to warn by requesting that a warning notification is sent. Wietse
Question about service daemon man pages
Hello, I have a question about the man pages for the service daemons that are executed via master(8). A section that is shared in all of the service daemon man pages is "CONFIGURATION PARAMETERS". In bounce(8) there are parameters under this section that relate to delivery status notifications. For instance: delay_notice_recipient. This made me think that bounce(8) is solely responsible for DSN's. When I check cleanup(8) under "CONFIGURATION PARAMETERS" I see: delay_warning_time which also relates to DSN's. I understand that both of these parameters are configured in one place: main.cf but my questions are: 1. When a parameter is listed under "CONFIGURATION PARAMETERS" does that mean it _only_ applies to its' service daemon ? This would mean that: delay_notice_recipient is "owned" via bounce(8) and: delay_warning_time is "owned" via cleanup(8) 2. If question 1 is correct why does DSN functionality have it's implementation divided between 2 daemons ? 3. Do other service daemons subdivide responsibility for a function ? For clarity - questions 2 and 3 aren't a critique of the design; it's more to help my brain understand things (one functionality provided by one service daemon is currently more understandable to my confused brain!). Thanks, - J
