|
Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com |
Subject: Re: ETRN too fast!
From: Rask Ingemann Lambertsen (rask-postfix
kampsax.k-net.dk)Date: Wed Sep 27 2000 - 20:01:13 CDT
- Next message: Rask Ingemann Lambertsen: "Re: [Q] Virtual Domains & ETRN"
- Previous message: Amos Gouaux: "Netscape LDAP SDK"
- In reply to: Wietse Venema: "Re: ETRN too fast!"
- Next in thread: Daniel Roesen: "Re: ETRN too fast!"
- Next in thread: Len Conrad: "Re: ETRN too fast!"
- Reply: Rask Ingemann Lambertsen: "Re: ETRN too fast!"
- Reply: Daniel Roesen: "Re: ETRN too fast!"
- Reply: Wietse Venema: "ATRN, connection cacheing (was: ETRN too fast!)"
- Reply: Robert A. Rosenberg: "Re: ETRN too fast!"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Den 27-Sep-00 16:56:12 skrev Wietse Venema fĝlgende om "Re: ETRN too fast!":
>Daniel Roesen:
>> I'm thinking about implementing a POP3 server extension and/or
>> implementation which authenticates users and informs Postfix to
>> send their mail to the IP which connected. Kinda ETRN for dynmic IP
>> dialup users.
>Configure a dynamic transport map that knows on what IP address
>the client is connected. Maybe an interface to Radius?
What's wrong with good old DNS all of a sudden? How about an interface
to DNS? Well, guess what, it is already there. Postfix can lookup the IP
address of a hostname and establish an SMTP connection to that IP address.
Trust me, I know it can, it happens all the time. ;-)
I sort of admire all the crazy ideas you people come up with, and no
doubt there would be great satisfaction in implementing it and seeing it
work, but this really isn't rocket science. It really is as simple as a
transport map entry:
yourcustomer.com smtp:[customerid.dynip.com]
There! One single single transport map entry that you don't even have to
modify afterwards. Try to beat that.
Between the various services similiar to dynip.com out there, I'm sure
you can find one which supports your customer's platform.
Should you still want to overburden Wietze with new things to add to
Postfix, try ESMTP ATRN (RFC 2645), but IMHO, it fills a much needed gap.
ETRN doesn't have the security problems of ATRN and is much simpler to
implement in the server as well as in the client.
Regards,
/ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻTŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ\
| Rask Ingemann Lambertsen | E-mail: mailto:rask
kampsax.k-net.dk |
| A4000, 896 kkeys/s (RC5-64) | "ThrustMe" on XPilot, ARCnet and IRC |
| If you wake up Sleepy & Grumpy, you must be Snow White. |
- Next message: Rask Ingemann Lambertsen: "Re: [Q] Virtual Domains & ETRN"
- Previous message: Amos Gouaux: "Netscape LDAP SDK"
- In reply to: Wietse Venema: "Re: ETRN too fast!"
- Next in thread: Daniel Roesen: "Re: ETRN too fast!"
- Next in thread: Len Conrad: "Re: ETRN too fast!"
- Reply: Rask Ingemann Lambertsen: "Re: ETRN too fast!"
- Reply: Daniel Roesen: "Re: ETRN too fast!"
- Reply: Wietse Venema: "ATRN, connection cacheing (was: ETRN too fast!)"
- Reply: Robert A. Rosenberg: "Re: ETRN too fast!"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]