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?
> 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. 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.
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. 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.
> 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".
> 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.
> 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.
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.)
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.
Regards,
Graham
--
-----------------------------------------
[EMAIL PROTECTED] "There's a moon
over Bourbon Street
tonight..."
S/MIME Cryptographic Signature
