Re: Opensmtpd failover
This kind of mail has no place in a list with hundreds of subscribers. Will only say this once: I'm more than willing to ban people from sending to the list in order to avoid the bulk from being spammed with this kind of exchanges. Discussion closed. On Thu, Nov 29, 2018 at 11:41:04AM +, Craig Skinner wrote: > Thomas, you're a stupid, standards breaking, sack of shit. > > STOP EMAILING ME PRIVATELY YOUR FUCKWIT CRAP!!! > > MX records have a purpose. Read what they are for. > > > STOP SENDING ME YOUR FUCKWIT PRIVATE IDEAS ABOUT MX RECORDS > > > > On Wed, 28 Nov 2018 13:06:03 Craig Skinner wrote: > > On Wed, 28 Nov 2018 02:41:42 +0100 Thomas Bohl wrote: > > > ... Who cares about the original concept of MX priorities? > > > > You're a fucking stupid arsehole Thomas. > > > > Due to you emailing me off list, you seem to want me to mentor you > > from being a postmoron into becoming a postmaster. > > > > For private tuition, I charge GB??60/hour. PayPal me GB??3,000 to start. > > > > Pay up. > > -- > > Craig Skinner | http://linkd.in/yGqkv7 > > -- > You received this mail because you are subscribed to misc@opensmtpd.org > To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org > -- Gilles Chehade @poolpOrg https://www.poolp.org tip me: https://paypal.me/poolpOrg -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: Opensmtpd failover
Thomas, you're a stupid, standards breaking, sack of shit. STOP EMAILING ME PRIVATELY YOUR FUCKWIT CRAP!!! MX records have a purpose. Read what they are for. STOP SENDING ME YOUR FUCKWIT PRIVATE IDEAS ABOUT MX RECORDS On Wed, 28 Nov 2018 13:06:03 Craig Skinner wrote: > On Wed, 28 Nov 2018 02:41:42 +0100 Thomas Bohl wrote: > > ... Who cares about the original concept of MX priorities? > > You're a fucking stupid arsehole Thomas. > > Due to you emailing me off list, you seem to want me to mentor you > from being a postmoron into becoming a postmaster. > > For private tuition, I charge GB£60/hour. PayPal me GB£3,000 to start. > > Pay up. > -- > Craig Skinner | http://linkd.in/yGqkv7 -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: kill -HUP not working as expected
Hi Gilles, On 11/29/18 9:17 AM, Gilles Chehade wrote: there are multiple reasons behind that: - smtpd can be killed/restarted right away without having to do cleanups and given that other MTA are supposed to retry transfers if connection drops, the complexity of dealing with reloading when you could just do a plain restart was not worth it. reload would be nice, it's not a big deal as far as i'm concerned and not high on my todo. I agree that this is not a high-prio task. But when I sent a HUP to smtpd, it was gone afterwards. Thats the unexpected part, but maybe it is still better then silently ignoring the HUP, still running the old configuration. My suggestion would be to mention it in the man page. Thanx very much. Keep on your good work Harri -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: kill -HUP not working as expected
On Thu, Nov 29, 2018 at 08:41:03AM +0100, Harald Dunkel wrote: > Hi folks, > > I learned some time ago that daemons restart or reload their config > file, when they receive a HUP. sendmail, sshd and tons of others do. > > smtpd doesn't. :-( > there are multiple reasons behind that: - smtpd can be killed/restarted right away without having to do cleanups and given that other MTA are supposed to retry transfers if connection drops, the complexity of dealing with reloading when you could just do a plain restart was not worth it. reload would be nice, it's not a big deal as far as i'm concerned and not high on my todo. - until a few releases ago, configuration was read by the parent process and children would inherit it through fork() so reloading was not even an option, but eric@ solved this. - until 6.4 the handling of configuration did not allow reloading due to how it works, an issue solved with the new grammar and config format. - until 6.4 parsing of the configuration was not properly isolated and a lot of side-effects could happen in the daemon when the parser was ran so it was not possible to parse a new configuration without breaking a currently running one, an issue that I solved. with recent developments we moved from a situation where reloading could not be done to a situation where someone willing to spend a few hours on that issue could probably solve it. i'll continue moving towards that direction but reloading not being very important in my mind it might take time, if someone wanted to work on it i'd help with getting started though ;-) -- Gilles Chehade @poolpOrg https://www.poolp.org tip me: https://paypal.me/poolpOrg -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org