Re: What's the idea behind "not enough disk space" "temporarily rejecting messages"
Sounds like a good solution :D On 06/10/14 10:20, Gilles Chehade wrote: a different approach was used for this, we reserve 100 blocks at startup which is what Sendmail does on OpenBSD, if it has worked for years, it should keep working. On Tue, May 20, 2014 at 02:29:41PM -0700, Barbier, Jason wrote: restart away good man it is a topic that should be discussed because we honestly should beable to set when it decides to reject since as some one pointed out 5% of a 1tb disk is like 50gigs, and no where near full. On Tue, May 20, 2014 at 12:20 PM, Gilles Chehade wrote: This has not been forgotten, the conversation with fellow hackers has led to nowhere but I'm about to restart it with a diff :-) On Tue, May 13, 2014 at 03:35:56AM -0700, Barbier, Jason wrote: Hmm, I see. at worst you now locked yourself out. I've already got the ext4 reserved blocks covering for that. Of course, not every file system has something like that. Even with reserve blocks it is still quite possible to fill the disk up past the reserve blocks. Never rely on a feature like that to save you from yourself ;), Ive had a few systems that were a fun disaster because the disk hit 105% full. But also every MTA does this also and you will be hard pressed to find one that doesn't. Indeed. postfix, for example, has a limit of 1.5 ?? message_size_limit. Way more sane, imho. Im not advising the limit is sane, it should/could be a knob, which is probably a discussion to have now. To be fair I as the admin should be able to decide how much I want to fill my queue folder, since in all fairness my queue folder could not be in /var/spool I could have moved it to a san where it shares space with other mission critical applications and has 50 terabytes of storage, and I really don't care if the disk fills past 5% because really it wont effect anything for the disk to get to near zero and I will always be able to recover from it filling. but that means your script or app needs to learn to be more resilient Any standard solutions for cron/at to do that? Standard no, many ideas, yes. If you just bebop around the internet there are many great examples of scripts that are resiliant. Since Im not sure what your scripts are written in I can only give you generic advice which is if you use the sendmail sender as the wrapper it should return a success/fail result and you could case or if/else for that result so it becomes in essence: Check for unsent queue and try to send Try to send new mail if Success exit if fail count=1 try again if fail count=2 write mail to disk (maybe pickup directory so it will get sent at some point when the mailer recognizes it) -- Jason Barbier | jab...@serversave.us Pro Patria Vigilans -- Gilles Chehade https://www.poolp.org @poolpOrg -- Jason Barbier | jab...@serversave.us Pro Patria Vigilans -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
anyone with an OpenSSL < 1.0.0 ?
Hi, After spending the last hour on this: https://github.com/poolpOrg/OpenSMTPD/commit/452d68767cd616cfa92606258119b74308c3edc7#diff-ceef0aa7bec5d64345287a4bc2c23cba I'm actually wondering why we bother, and if we should not just kill the support for pre-1.0.0 OpenSSL at configure time and get rid of the check for good. Any maintainer of a package that runs on a system that still uses <1.0.0 wants to object ? -- Gilles Chehade https://www.poolp.org @poolpOrg -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
[MAINTAINERS] please read this mail :-)
On Wed, Jun 11, 2014 at 12:45:20AM +0200, gil...@poolp.org wrote: > User gilles has just rebuilt a portable snapshot, available from: > > http://www.OpenSMTPD.org/archives/opensmtpd-201406110044p1.tar.gz > > [...] > > - OpenSSL version detection was broken, the following fixes it for >1.0.0 > versions > In the compat layer, there is a check to ensure that the runtime OpenSSL is API/ABI compatible with the version that was used to build OpenSMTPD. The check was incomplete and as a result some people have experienced an issue where OpenSMTPD would fail to start after an OpenSSL upgrade. $ smtpd fatal: OpenSSL version mismatch. [...] The check was rewritten slightly differently and works fine with all the version tests I did manually. Please test and let me know if you hit it again. -- Gilles Chehade https://www.poolp.org @poolpOrg -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
[OpenSMTPD] portable snapshot opensmtpd-201406110044p1 available
User gilles has just rebuilt a portable snapshot, available from: http://www.OpenSMTPD.org/archives/opensmtpd-201406110044p1.tar.gz Checksum: SHA256 (opensmtpd-201406110044p1.tar.gz) = 316caf50217726c9cc4872d255613684febf7fa2c9d2c6138c2d067463ce8e85 A summary of the content of this snapshot is available below. Please test and let us know if it breaks something! If this snapshot doesn't work, please also test with a previous one, to help us spot where the issue is coming from. You can access all previous snapshots here: http://www.opensmtpd.org/archives/ The OpenSMTPD team ;-) Summary of changes since last snapshot (opensmtpd-201406061833p1): - - add space to log output to have consistent identation and reword to clarify [1] - implement listen "no-dsn" option to disable DSN on a specific listener [2] - add support for variadic parameters in fatal() and fatalx() - no longer rely on percent-based disk space reserve, instead reserve 100 blocks - various queue-proc related updates - when using queue encryption, do not prompt for password at config parse time - do not allow the same parameter to be specified twice on a listen line - use fatalx() instead of errx() in table.c so table errors are logged - OpenSSL version detection was broken, the following fixes it for >1.0.0 versions [1] Author: tom hensel [2] Author: Emmanuel Vadot -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
[OpenSMTPD] master snapshot opensmtpd-201406110039 available
User gilles has just rebuilt a master snapshot, available from: http://www.OpenSMTPD.org/archives/opensmtpd-201406110039.tar.gz Checksum: SHA256 (opensmtpd-201406110039.tar.gz) = 9082a22615dba0fc4979ba82396dc5e5c1d879db2e02c2e5970eeec8decd7624 A summary of the content of this snapshot is available below. Please test and let us know if it breaks something! If this snapshot doesn't work, please also test with a previous one, to help us spot where the issue is coming from. You can access all previous snapshots here: http://www.opensmtpd.org/archives/ The OpenSMTPD team ;-) Summary of changes since last snapshot (opensmtpd-201406061829): --- - add space to log output to have consistent identation and reword to clarify [1] - implement listen "no-dsn" option to disable DSN on a specific listener [2] - add support for variadic parameters in fatal() and fatalx() - no longer rely on percent-based disk space reserve, instead reserve 100 blocks - various queue-proc related updates - when using queue encryption, do not prompt for password at config parse time - do not allow the same parameter to be specified twice on a listen line - use fatalx() instead of errx() in table.c so table errors are logged [1] Author: tom hensel [2] Author: Emmanuel Vadot -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: What's the idea behind "not enough disk space" "temporarily rejecting messages"
a different approach was used for this, we reserve 100 blocks at startup which is what Sendmail does on OpenBSD, if it has worked for years, it should keep working. On Tue, May 20, 2014 at 02:29:41PM -0700, Barbier, Jason wrote: > restart away good man it is a topic that should be discussed because we > honestly should beable to set when it decides to reject since as some one > pointed out 5% of a 1tb disk is like 50gigs, and no where near full. > > > On Tue, May 20, 2014 at 12:20 PM, Gilles Chehade wrote: > > > This has not been forgotten, the conversation with fellow hackers has led > > to nowhere but I'm about to restart it with a diff :-) > > > > On Tue, May 13, 2014 at 03:35:56AM -0700, Barbier, Jason wrote: > > > > Hmm, I see. > > > > > > > > at worst you now locked yourself out. > > > >> > > > > I've already got the ext4 reserved blocks covering for that. Of > > > > course, not every file system has something like that. > > > > > > > Even with reserve blocks it is still quite possible to fill the disk up > > > past the reserve blocks. Never rely on a feature like that to save you > > from > > > yourself ;), Ive had a few systems that were a fun disaster because the > > > disk hit 105% full. > > > > > > > > > > > > > > But also every MTA does this also and you will be hard pressed to find > > > >> one that doesn't. > > > >> > > > > Indeed. postfix, for example, has a limit of 1.5 ?? message_size_limit. > > > > Way more sane, imho. > > > > > > > Im not advising the limit is sane, it should/could be a knob, which is > > > probably a discussion to have now. To be fair I as the admin should be > > able > > > to decide how much I want to fill my queue folder, since in all fairness > > my > > > queue folder could not be in /var/spool I could have moved it to a san > > > where it shares space with other mission critical applications and has 50 > > > terabytes of storage, and I really don't care if the disk fills past 5% > > > because really it wont effect anything for the disk to get to near zero > > and > > > I will always be able to recover from it filling. > > > > > > > > > > > > > > but that means your script or app needs to learn to be more resilient > > > >> > > > > Any standard solutions for cron/at to do that? > > > > > > > Standard no, many ideas, yes. If you just bebop around the internet there > > > are many great examples of scripts that are resiliant. Since Im not sure > > > what your scripts are written in I can only give you generic advice which > > > is if you use the sendmail sender as the wrapper it should return a > > > success/fail result and you could case or if/else for that result so it > > > becomes in essence: > > > Check for unsent queue and try to send > > > Try to send new mail > > > if Success exit > > > if fail count=1 try again > > > if fail count=2 write mail to disk (maybe pickup directory so it will get > > > sent at some point when the mailer recognizes it) > > > > > > -- > > > Jason Barbier | jab...@serversave.us > > > Pro Patria Vigilans > > > > -- > > Gilles Chehade > > > > https://www.poolp.org @poolpOrg > > > > > > -- > Jason Barbier | jab...@serversave.us > Pro Patria Vigilans -- Gilles Chehade https://www.poolp.org @poolpOrg -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: How to configure encryption ciphers and SSL/TLS protocols
On Mon, 9 Jun 2014 10:16:43 +0200, you wrote: >On Mon, Jun 09, 2014 at 08:39:52AM +0100, John Cox wrote: >> Hi >> >> >>That's not correct no, I get plenty of TLS 1.0 trafic and it has been >> >>the case for many years >> > >> >To parrot this on all of my various instances OpenSMTPD and not I get tons >> >of TLS 1.0 and SSLv3 traffic, I wish I didn't but it still happens. Heck >> >every now and again I see SSLv2 attempts which for most of my instances get >> >killed. I haven't seen one on my OpenSMTPD instance yet but its only time. >> >But seriously for email any transport encryption is better than none and >> >OpenSMTPD's default should be the best way to handle opportunistic TLS >> >where you always try to use the highest protocol version supported with the >> >best ciphers supported, and there shouldnt need to be a knob for it. >> >> Whilst I agree with what you are saying for general purpose mail >> servers, I can see applications where enforced encryption levels are >> worth having. I can see that some company gateways, where they know >> all of the other endpoints, might wish to enforce appropriate >> encryption as everybody who should be talking to that MTA should be >> capable of it and anything else is therefore spam or hacking. This is >> particularly plausible on any link where TLS or SSL is already >> mandatory. >> > >please define "enforced encryption levels" ? Tricky - I don't have a specific use case in mind, but I worked on building a military email system (X.400 based - it was that long ago, though they may still use it for all I know) and they were pretty keen on nailing down exactly what was expected on each link. >pretty much anyone tweaking ssl_ciphers will actually downgrade security >or/and break interop with other servers. some people may know how to tie >things further for their specific use-cases but the minute we add a knob >other people will start using it and shoot themselves in the foot. Sadly that is the case with pretty much all security, but the lack of an ability to check/filter based on what security level has been negotiated means that those people who _do_ know what they are doing can't. I'm still annoyed by the general (not smtpd particularly) impossibility of having usefully functioning CRLs, which are pretty much a requirement of any PK system but have been generally ignored to date. >At the time being we're looking to is to have the bul0k of users safe by >default and we're looking for more: > > https://twitter.com/Mayeu/status/474109854651785216 > >"the magic of OpenSMTPD, you do no TLS configuration and you're graded A > by default <3 (test here: starttls.info)" I do not disagree >Im not saying that this will hold true forever but at this point in time >I would prefer that we dont have ssl_ciphers and that any improvement we >do is made to the default until we exhausted all possibilities to do so. Fair enough - I just felt it was worth adding another point of view to the discussion. Thanks JC -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
