|
Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com |
From: Michael Tokarev (mjt
tls.msk.ru)Date: Fri Nov 02 2001 - 11:14:32 CST
Ralf Hildebrandt wrote:
>
> On Fri, Nov 02, 2001 at 10:47:37AM +0200, Pyuesh Daya wrote:
>
> Please wrap your lines to 74 characters. It's a pain to answer.
>
> > Let me explain my process. I have made an ip address 1.2.3.4 active on
> > our network. In the transport file, as domains ip is set to 1.2.3.4. When
> > some clients connect, the file is edited and the dummy ip is replaced with
> > the dialup ip address. Once the postmap is run on the transport file, and
> > etrn command is automatically issue to the server to queue mail for this
> > domain in question. This is all in about 2 seconds that all this happens.
>
> Ah. That means anybody can steal your mail, since ETRN is not authenticated.
>
> Anyway: The mail is already queued -- the qmgr takes no notice of the
> changed transport_map. For that, you'd need to requeue the mail for that
> domain!
Umm... Nope. Transport map entries aren't stored in queued messages,
but qmgr will look into transport_map when it will process the message.
So -- no, qmgr will pick up NEW transport map entry. Note however that
in case transport map change, qmgr will restart.
Wow, interesting point: qmgr can benefit from having "self-reloading"
maps, i.e. for some map types like e.g. berkeley db3, there is no need
to reload it after a modification. Also, for non-chrooted process, it
can just reopen a map after a change -- for qmgr on large sites it may
be very useful. A time for "map reload jumbo patch"? ;)
Regards,
Michael.
-
To unsubscribe, send mail to majordomo
postfix.org with content
(not subject): unsubscribe postfix-users
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]