OSEC

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 (mjttls.msk.ru)
Date: Fri Nov 02 2001 - 11:14:32 CST

  • Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

    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 majordomopostfix.org with content
    (not subject): unsubscribe postfix-users