Re: Opensmtpd failover

2018-11-29 Thread Gilles Chehade
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

2018-11-29 Thread Craig Skinner
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

2018-11-29 Thread Harald Dunkel

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

2018-11-29 Thread Gilles Chehade
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