Date: Fri, 27 Sep 2002 18:40:18 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Tony Finch <dot@dotat.at> Cc: current@freebsd.org Subject: Re: Journaled filesystem in CURRENT Message-ID: <3D950882.116D1FD7@mindspring.com> References: <200209251319.g8PDJYoD047918@ib.com.ua> <20020925111232.B3686@Odin.AC.HMC.Edu> <20020926111949.5c0da160.Alexander@Leidinger.net> <20020926090325.A24614@zardoc.esmtp.org> <3D93459B.E4405568@mindspring.com> <20020926113551.A11092@zardoc.esmtp.org> <E17uwy4-0007Zy-00@chiark.greenend.org.uk> <E17v4qs-0006Sv-00@chiark.greenend.org.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
Tony Finch wrote: > Terry Lambert <tlambert2@mindspring.com> wrote: > >Tony Finch wrote: > >> Exim doesn't do per-domain queue runs; when it successfully delivers > >> mail to a host it checks its hints database for any queued mail that > >> can go to the same place and shoves them down the same connection -- > >> no scanning of multiple files involved. > > > >So how does it implement ETRN and ATRN? > > They're both sufficiently unimportant not to make it worth complicating > the MTA to optimise them. AKA "It doesn't". 8-) 8-). > Exim lets you specify a shell command that is > run in order to implement these SMTP commands, so it's up to you whether > this involves a queue run (with exim -R) or not. For example, you might > route incoming mail to a dial-up host and use the appendfile transport > to dump it in a directory with use_bsmtp, and cause ETRN commands to > run over that directory. (Although the latter requires extra code.) > > I'm interested that you think ETRN is important, because to me it seems > the wrong solution given POP with the *ENV extension, or decent IMAP. POP3 is uninteresting because you don't get the opportunity to reject the email before taking responsibility for delivering it, IMAP4 is ununteresting for that reason, and because of the amount of storage space required. I understand Mark Crispin's goals in designing IMAP4, but, practically, it's not very usable in a traditional ISP setting, any more than POP3 is, when what you are dealing with isn't local users (and implementing Sieve is generally not an option, both because it's computationally expensive to run filters on the ISP side, and because the mail clients aren't really built to replicate filter information to a mail server, even if you accepted the computational overhead). Generally, IMAP4 is not used in commercial mail services, because of where the value proposition is loaded in commercial mail services -- both because of how mail clients have been traditionally designed, and because of the service overhead. To be blunt, IMAP4 costs money, and POP3 makes money. ETRN (and ATRN) solve a totally different problem, actually. They solve the MTA store-and-forward problem for differential queue run latencies. The most common case of this is a transiently connected terminal email server for a domain where there are permanently connected MX's which only store and forward. In the context of the FS discussion -- which is the context in which this mail server discussion is taking place -- the issue is one of the ability of the mail server to permit email to transit it. There are really only three cases where this happens in high enough volume that anyone cares about FS performance: 1) Store and forwarding of queue contents for transiently connected mail servers (e.g. ETRN, ATRN, finger-based queue running, RADIUS accounting record triggered queue running, etc.). 2) Local delivery to a local maildrop (POP3/IMAP4/etc.), in which case queue performance is a heck of a lot less important than that of the local delivery agent -- but that's not what we were discussing. 3) If you are an open relay for SPAM. Frankly, if we are talking about #3, I'd just as soon your machines became so damaged that they could not be rebooted. If it could catch on fire, and burn down the hosting facility that wa willing to sell connectivity to a SPAM'mer, well, that would just be gravy. 8-). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3D950882.116D1FD7>