qmail at honorablemenschen
Aug 17, 2010, 8:51 AM
Post #4 of 19
(1548 views)
Permalink
|
> Hi,
>
> Am Dienstag, den 17.08.2010, 10:26 -0300 schrieb Rejaine Monteiro:
>>
>> hello,
>>
>> I read the articles below about qmail :
>>
>> http://www.dt.e-technik.uni-dortmund.de/~ma/qmail-bugs.html (4.3
>> Bandwith hogging)
>>
> Personally, I'm not very pleased that Matthias Andree still uses the
> Webserver of the University of Dortmund to host his private opinion.
>
> Anyway. As Dave Sill pointed out: This is not a bug; it is a design
> decision of DJB and it touches deeply the way emails are kept in the
> Message Store, the queue.
>
> At that time when DJB wrote qmail, RFC 821 was relevant and it defines
> SMTP mail as <transaction>. Later, with RFC 2821 (the famous Klensin
> draft) with ESMTP a <session> was introduced (you find more details
> about that on my SMTP Auth web site).
>
>> and this
>>
>> http://www.lifewithqmail.org/lwq.html#multi-rcpt
>>
>> Does not really exist any possiblity to implement the multi-RCTP on
>> qmail?
>
> qmail stores each email at two locations: the SMTP envelope and the
> message itself and references those by their (identical) INODE name.
>
> It would at least require a substantial change in qmail-rspawn to gather
> several mails for one domain in one transaction with multiple RCPT To:
> in case the message itself is identical, thus it can be transmitted with
> one DATA command (this is actually the bandwidth critical path).
>
> I'm going to have a look for my forthcoming SPAMCONTROL patches, but I
> can hardly promise anything.
>
I have done a lot of looking at this and considering the whole issue and I
have reached the following conclusions:
1) You are correct, there is no way to do multi-RCPT in qmail as it
stands. This is not just a qmail-remote issue, it's also embedded in
qmail-rspawn and qmail-send. If I ever get the time and motivation to
write the MTA I've been contemplating for a while, this is one of the
things that I intend to make it capable of doing (though not forcing the
admin to do so).
2) The pros and cons of single- vs. multi-RCPT are MANY, and there is no
one correct answer. RFC2821 is still technically Draft, and not Standard,
which means that violating a SHOULD in it is a non-issue. That being
said, most current MTAs have been written with 2821 in mind, so it's at
least worth considering.
3) The biggest con of single-RCPT is large domains (I'm looking at you,
Yahoo!) that are hosted across many servers but impose fairly strict
limits on the number of inbound connections at any one time. For those
SPECIFIC domains, a multi-RCPT MTA will likely have better delivery
performance over the long run, and almost certainly over periods of large
message volume - this is why I developed my concurrency-per-IP patch
(http://www.coyotetechnical.com/software/patches/qmail-send-concurrencyperip.patch)
to limit the number of connections to any one server IP at a time.
However, outside of those conditions (which are almost 100% caused by
configuration decisions on the part of another site's mail admins) there
is no big need for multi-RCPT delivery. It may be a little more
efficient, but unless you're sitting on dial-up or require instant email
delivery (in which case, why are you using SMTP?!?), bandwidth is usually
NOT your bottleneck...
Everyone's a critic - that's why there are several different open-source
MTA options out there. If multi-RCPT is your #1 requirement, then go
ahead and use something other than qmail - it makes no difference to me.
Just remember that qmail is designed the way it was designed for a lot of
reasons, and just because you (or someone else) disagree with those
reasons, doesn't mean it's "wrong" - just wrong for your specific
application.
Josh
Joshua Megerman
SJGames MIB #5273 - OGRE AI Testing Division
You can't win; You can't break even; You can't even quit the game.
- Layman's translation of the Laws of Thermodynamics
qmail [at] honorablemenschen
|
signature.asc
