login
Search
Hi All, Could you please inform about the actual state of OpenSMTPd and when it shall be fully integrated into OpenBSD ? Thanks.
You can keep an eye on its development by tracking commits on the CVS repository. I cant tell as I am not using it currently but I would say its already integrated and pretty usable for common scenarios, not yet fully, if at all, ready for production. calomel.org has an article that can give you an idea of its actual state. gilles@ or jacek@ can add more insight into this anyway. Have a nice day Iqigo
Does it have the same reliability features as qmail on an FS without softupdates? What about with softupdates? http://cr.yp.to/qmail/faq/reliability.html
If you use softupdates you assume certain risks. What the fruit does it have to do with smtpd?
the very link you just provided contains the following sentence: Do not use async or softupdates filesystems.
On Thu, Jan 14, 2010 at 4:26 PM, Denis Doroshenko Sorry, forget I mentioned softupdates. Does it do what qmail does? Reliaibility-wise? "qmail's queue, except for bounce message contents, is crashproof on the BSD FFS and most of its variants. "
Since the point of a mail server is to not lose mail, your question is basically "does it have any bugs?" That's kind of a silly question to ask for any piece of software, but maybe we could infer some information in this case. Is smtpd enabled by default? Has sendmail been deleted from src? Has there been an announcement saying "smptd is ready for production use"?
More like does OpenBSD have a similar reliability feature that qmail does - pertaining to writing messages into the queue? I didn't ask whether OpenSMTPD has bugs! Thanks!
qmail runs inside the os; it doesn't get to vote. How many more times do I need to repeat this? This question is nonsensical so I'll answer accordingly. Yes, blue is a
This is irrelevant. Of course it relies on the OS to work right. qmail's queuing reliability depends on FFS's atomicity, bugs in the kernel could of course screw anything up, or running queue with softupdates or async mount, or write-back cache without battery No offense, but I don't think the question was understood. qmail's qmail-queue does interesting, and a bit complicated things to deal with crashes while a message is being queued. See here: http://gd.tuwien.ac.at/infosys/mail/qmail/qmail-manual-html/misc/INTERNALS.ht ml qmail tries to be very careful that a message is on the disk. Does OpenSMTPD do this? The answer could be "yes" or "no". How is that nonsensical? Thanks!
The answer could also be yes and no, and indeed, it is. No, smtpd does not do what qmail does. Yes, smtpd tries to store the message on disk.
Only very big fool can write e-mail SW which don't try to have messages on the disk ;-)
Thanks for taking what I said out of context. Geez, all that crap I wrote about queuing is irrelevant! Good job.
I don't think that someone tries to stop you with tests of smtpd like '# smtpctl show queue' or '# ls -l /var/spool/smtpd/queue' with/without softupdates and check outputs and e-mails in queue. Eg. I wasn't sure if it's safe to remove messages from queue in case that my smtpd is set onfly for local delivery. I asked and I received some recommendations. I used them, but first I test to just simply remove them directly and everything was ok. You can update my answer : Gilles Chehade and Jacek Masiulaniec have all of this in their minds so there is a very low chance that they forgot about proper queueing or saving messages to disk.
*This* question makes sense. Your question two messages back, quoted above ("does OpenBSD have...") is what didn't make sense and sent Marco spinning into surrealist response. Perhaps you meant in that older message to instead say "does OpenSMTPD have..."? (As for your question: I don't know the answer. I'm quite comfortable with sendmail myself** and have other things I'm more interested in hacking on in OpenBSD so I haven't gotten around to checking OpenSMTPD over closely and can give neither positive *nor* negative feedback on its reliability.) Philip Guenther ** Disclaimer: I've contributed fixes to sendmail and have a professional relationship with Sendmail, Inc.
Nothing is crash prof. Can you please stop making these retarded statements? You are making a fool of yourself. If software people weren't so dangerous they'd be adorable.
I don't think this is an original sentiment. I think he's quoting DJB's faq. it's still an idiotic sentiment, but it does serve as a warning that his (DJB's) software should be treated with great care. kind of like the Xen guys the other day. Ben
(DJB's) software should be treated with great care. Hmm. Not sure I agree. All he's saying is that qmail is designed to use FFS's atomic update stuff, and aims not to lose messages. Doesn't mean it's bug-free.
And how does it ensure the hardware does what is says? In a timely manner? Hoe does it know? Oh wait, it doesn't. I design all my code to not lose data too. Someone call the press apparently I am on to something ground breaking.
smtp ensures reliability by working on a temporary queue during writes, then commiting messages (all of them, including bounces) to the real queue using an atomic rename. after a successful rename, smtpd tells the client it accepted the message. with this ordering, you can never have smtpd in a state where it has lost a message after accepting it or where a message is incomplete and corrupt in the queue because of a power shortage happening at a wrong timing. either the message is in queue or it's not, and if it's not then client/mua was not told message is accepted. Gilles -- Gilles Chehade freelance developer/sysadmin/consultant http://www.poolp.org
Right and at this point you hand it off to the hardware and it does whatever it does and lies whenever it wants to about completions, etc. If it is a raid controller for example, you dont know if it is in cache, being coalesced with other IO, deferred waiting on another IO, got reordered for some sort of optimization, partial incomplete because a disk hasn't caught up etc etc. You can do everything right all day long in software but hardware does what it does and claiming that a piece of software is crash proof is naive at best. I am not eluding to you Gilles, I am eluding to claims made in qmail and parroted by someone without a name on this list. I'd venture to say that the more magic one performs trying to force an OS and a piece of hardware to do something without having the proper dials
it was implied by your previous post :-) i was just decribing what smtpd from a code point of view. smtpd does it best and i believe it is no less reliable than qmail or postfix wrt handling of messages in queue, but obviously smtpd cannot provide more guarantees than the filesystem itself provides. -- Gilles Chehade freelance developer/sysadmin/consultant http://www.poolp.org
You do know if you know your hardware. How is this relevant to what Funny how these discussions quickly turn into personal attacks... Anything wrong with quoting someone? I am not making claims, the qmail's author does... He wrote qmail, it's up to him to explain what it does and doesn't do. Also, it's not the MTA's job to ensure the hardware does what it's supposed to. It neither obviously can even attempt to do that, nor is it's job to do that. I've never implied that it's MTAs job to control the kernel or hardware. It's the administrator's job to buy and configure the right kind of hardware for the MTA. It's his/her job to make sure it writes correctly to the disk. qmail's author says "Queue reliability demands that single-byte writes be atomic. This is true for a fixed-block filesystem such as UFS, and for a logging filesystem such as LFS." This implies that the FS code and the hardware does the right thing for the queue to be reliable. http://www.qmail.org/man/misc/THOUGHTS.txt http://cr.yp.to/qmail/faq/reliability.html#filesystems He also writes "You may encounter people who dispute one or more of the above statements. Those people don't know what they're talking about. A rather spectacular example appeared in February 2001, when someone wrote hundreds of lines of text in a dozen messages claiming that my FAQ was ``totally incorrect,'' claiming that the BSD FFS wrote data to disk in the wrong order, claiming that the BSD FFS was not crashproof, and claiming that qmail was not crashproof. He put a tremendous amount of effort into making his claims sound authoritative. ``I think there *might* be a dozen people in the world that understand UFS/FFS better then I do, but none of them have posted to this thread,'' he said. He repeatedly claimed that his assertions were well-known facts that had motivated the design of subsequent filesystems. Eventually, after a discussion with two people who understood FFS better than he did, he withdrew his claims and ...
I said it before if software people weren't so dangeorous they'd be adorable. I haven't read his bs and couldn't me arsed to; your sneak preview tells me everything I have to know about him. But don't believe me to read the block sorting algorithm. Or the SCSI spec that asserts that ios complete out of order. I only have developed strorge products for 15 years so what do I know?
I hope that doesn't mean what I interpret it to mean, because if you write one byte to the beginning of a file and one byte to the end of a file, there's no guarantee which byte hits the disk first. The other interpretation of it, meaning that you won't ever write half a byte, is true, but strikes me as exceptionally obvious and true of every filesystem. So what does it mean for a single byte write to be atomic?
That some bits in a byte won't be updated without other bits being updated as well.
Considering how much extra work a filesystem would have to go through to enable that to be untrue, it seems silly to call it out as something special.
On Fri, Jan 15, 2010 at 3:55 AM, Gilles Chehade <gilles@openbsd.org> wrote:>> "qmail's queue, except for bounce message contents, is This is the answer I was looking for. Thanks!
Then you should have asked the question you wanted answered. paulm
I am familiar with DJB's writings on queue structure and others. Fundamentally, OpenSMTPD makes use of file system atomic operations similarly to qmail in order to achieve the same goal, the difference lies in directory hierarchy organization which that is of secondary importance. But I believe Marco when he says atomic operations do not give you guarantees in the strict sense of the word.
actual state ? work in progress, do not use in production, you will lose your job. when will it be fully integrated ? hard to answer, but until there's an official announcement that smtpd is the default MTA on OpenBSD, don't assume it is ready. Gilles -- Gilles Chehade freelance developer/sysadmin/consultant http://www.poolp.org
On Fri, 15 Jan 2010 09:41:46 +0100 actually, I already use it on a couple of my low volume servers. Both as a receiving and as a sending mta. Works just great. -- With best regards, Gregory Edigarov
Thanks , I am likely to wait for it to be ready before I set up my first mail server, just because I trust in OpenBSD's way to intergate security in the software, and because my servers need not to be sensitive to hacking as it today is full of on the internet. Regards
