On Tue, Mar 16, 2004 at 10:44:25PM +0100, Claudio Jeker wrote: > > MTA<->MTA SMTP AUTH is not supported by qmail-ldap, too (I requestetd > > this "feature" some time ago). > > > > In the upcomming release AUTH LOGIN will be supported by qmail-remote.
Great - nice to hear that. Then I can mv the 2nd qmail instance (which does currently the outgoing auth. stuff) to /dev/null. > > However, I'll have a look at AutoTURN from djb's serialmail package. > > > > "AutoTURN delivery from the ISP. After the dialup computer makes an > > SMTP connection to the ISP, it automatically receives an SMTP connection > > back from the ISP if there is any new mail for it. This provides the > > same power as ETRN but does not require a special client." > > > > This, combined with TLS (of course), sounds like a good solution. > > > > Hmm. I don't think so. If I remember correctly the cert stuff implemented > by the tls patch used the DNS name to find the client cert. So in your > DynDNS setup you will suffer from the same problem. Why? I had thought this way: I tell the MX foobar.dyndns.org's certificate. Then deliverys would not send to any mailserver with the dyndns-name (e.g. in the time the IP is updated mails can be send to foreign server), but only to this with the right certificte... I hope its now clear what I mean :) > For dynmaic IPs SMTP AUTH is almost the only solution (or pop before > smtp). Hm. My attempt is to ensure that the mail server on the internet dont deliver so anybody else then my MTA. SMTP AUTH won't help here. As mentioned above, AutoTURN will be the best. I think you mean the reverse situation (a DynDNS client sends mail..). Then, SMTP AUTH is of course the best idea. Oskar
