On Thu, Aug 16, 2001 at 10:31:47PM +0200, Graham Leggett wrote:
> Henning Brauer wrote:
> > That's exactly the way clustering in qmail-ldap works. If any host is
> > qmail-ldap, why the heck tyhe deliveries should be done over smtp? All hosts
> > are able to speak qmqp then.
> Obviously - but all the hosts have to speak SMTP anyway (to receive mail
> from clients and foreign MTAs) so what's the point in running QMQP?
efficiency, reliability, pure speed. ressource consumption, delivery time.
> > It is. You must run qmail-qmqpd under tcpserver (inetd & co should be
> > possible too, but who wants that...) and restrict access to IPs from your
> > local network/your other qmail-ldap hosts.
> Er - so in other words it isn't.
It is insecure, yes. You must restrict access to trusted hosts.
> An open port should be secure (ie not
> able to be abused) without having to add kludges around it like IP
> filters to protect it.
Huh? Access control via tcpserver, as for qmail-smtpd and many other
servers. Except that it defaults to deny.
> And then think about it - if you have ten mailservers and you add
> mailserver number eleven, then *ten* machines have to have their config
> changed to recognise that new machine.
It's usually safe to allw access to the qmail-qmqpd for your entire subnet.
> The scope for human error and the
> amount of completely unnecessary work is enormous. Remember these
> machines are not on the same subnet, or even in the same country, or
> even have the same administrator.
If one can't manage to change access control lists he should reallt think of
outsourcing his mail services.
> > Huh? If you run different MTAs on different platforms (which was the
> > original requirement if I'm not mistaken, there was talked about a
> > migration) you have to have the uids on each box anyway.
> You don't - all the box requires is that a particular email address is
> local to that box. How that box handles the mail isn't relevant to
> qmail-ldap - it's only job is "get the email to the right box".
Any mail injected at the foreign machine destined for the local domain but
for a user on a different system will be undeliverable.
Still broken design. Internet mail does not work this way.
> > Netscape Messaging server works this way, so there is precedant out
> > > there for this kind of behavior.
> > Some MTAs are open relays by default (and some are not even fixable), so
> > there is precedant out for tis kind of behaviour.
> This is a ridiculous statement. NSMS was given as an example of a
> successful design strategy that's been implemented in the marketplace
> and works well. Saying "there are bad design strategies out there too"
> isn't saying anything useful at all.
"Others do it this way" to things the same way. It is clearly documented
that in-cluster deliveries work over qmqp and not smtp. If you don't read
the docs...
> > Didn't said that, didn't meant that. You are trying to solve a problem. So
> > instead of describing the problem and asking for a solution you think of a
> > possible solution, notice it does not work and cry because it does not work
> > this way.
> You completely misunderstand my point. I have a specific design
> requirement in order to achieve something. Qmail adds *extra unnecessary
> complexity* to my design because it specifically does not support a
> particular feature. As a result Qmail supports only 90% of my design
> requirement. But - I have the source, which means I can change that last
> 10% so that Qmail will fit 100% of my needs.
Then don't talk, do. Don't write mails, code.
You are convinced that what you have is _the_ solution. I treat it as a
design failure. You misunderstand the way internet mail works IMHO.
Obviously we don't need to discuss this further. We won't agree.
You still insist on what you call your solution instead of answering a
simple question. "What problem are you trying to solve?".
> The trouble is that you are opposing the suggestions I have for
> achieving the last ten percent of my design requirement - and in doing
> so you are suggesting workarounds and kludges that *do not meet* my
> design requirements. My requirements are:
>
> - It must scale from one to n machines
> - All machines must have a virtually identical config and be consistent
> - All machines must share *one* authoritative LDAP account tree with
> *no* record duplication
> - Any user should be able to send mail via SMTP to any machine and mail
> delivery to the specific machine should "just work".
> - Any external MTA should be able to deliver any email for any locally
> hosted domain by connecting to any of these boxes, and mail delivery
> should "just work".
> - (The problem of getting the users to fetch their mail from the correct
> server is a separate problem, but easily solved.)
Not a single problem here as long as all machines are qmail-ldap, including
the last one. qmail-ldap supports session forwarding for pop3 and imap.
> Removing the restriction that mailHost-based mail delivery is only
> possible on QMQP and not SMTP will allow me to achieve the above with
> Qmail-ldap. If you can suggest something different that meets my
> requirements and is more elegant than I am all ears.
just use qmqp. qmqp is especially designed for this type of usage while smtp
is not.
--
* Henning Brauer, [EMAIL PROTECTED], http://www.bsws.de *
* Roedingsmarkt 14, 20459 Hamburg, Germany *
Unix is very simple, but it takes a genius to understand the simplicity.
(Dennis Ritchie)
