Still no need to Cc: me, I'm still on the list.
On Fri, Aug 17, 2001 at 12:12:45AM +0200, Graham Leggett wrote:
> Henning Brauer wrote:
> > > 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.
> At the expense of supporting two protocols instead of just one,
> increasing complexity, and decreasing security (in the form of potential
> mail abuse). This is not an acceptable tradeoff.
Nonsense. Why support pop3? ppl can get their mail via ftp.
Different protocols for different services.
> > It's usually safe to allw access to the qmail-qmqpd for your entire subnet.
> No it's not (and especially in my case where the local subnet is
> effectively the internet).
I wrote usually, and I mean usually. Usually != always, and internet !=
local subnet.
> > Any mail injected at the foreign machine destined for the local domain but
> > for a user on a different system will be undeliverable.
> Not true. The only requirement is that box thinks the domain for that
> address is local to that box. Remember that all ten machines believe
> that all domains are their "local domain".
That requires qmail-ldap on all machines. If so just use qmqp.
> > Still broken design. Internet mail does not work this way.
> Yes it does. Netscape Messaging server works this way very successfully.
Netscape Whatever != internet mail.
> > "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...
> ...and I am arguing that doing this over QMQP is the wrong approach in
> my case.
It is NOT. smtp has to many disadvantages for this kind of usage.
> I am not arguing as to whether doing it over SMTP is possible
> *now* or not, I am arguing that there is no reason that it shouldn't be
> possible.
There is a very valid reason for not doinf so: bloating the codebase without
a reason.
> > Then don't talk, do. Don't write mails, code.
> I already offered to, but you made it clear that if I submitted a patch
> to do this you would not accept it.
Andre maintains the main qmail-ldap patch, not me. I would not include such
a patch.
> > 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.
> Having been involved in the integration of a number of large email
> systems (the largest scaled at an initial capacity of 1.4 million
> mailboxes) I would disagree with you. This solution is not mine, but
> someone else's - it works. As yet you have not been able to give a
> reason why it's a bad idea, only that you have a different idea.
No. It's quite confusing what you are writing. One time we tralk about
foreign non-qmail-ldap systems, one time all are qmail-ldap. If all are
qmail-ldap, just use qmqp, the protcol designed for such stuff.
> > 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?".
> This question is answered in my next paragraph:
> > > 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.
> But QMQP is not secure without some form of explicit IP address based
> packet filter protection,
Nonsense. IP-based access control via tcpserver as you (hopefully) do for
nearly any service.
> on machines that are on the internet which
> adds an unacceptable adminstrative burden to the system. If QMQP had
> some form of security on it (TLS + client certificates, perhaps?) then
> it would be an option.
Nonsense. qmqp is desiged for deliveries between trusted hosts, how often
again? If they are not directly connected use VPNs. A good idea regardless
of qmqp, anyway.
> In the mean time SMTP may be less performance,
> but it works and is secure.
Nonsense. It adds an uneeded overhead.
--
* 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)
