mmdf mail delivery .forward file with backslash - SCO

This is a discussion on mmdf mail delivery .forward file with backslash - SCO ; Recently, a client site with mmdf for whom all email is pulled in with fetchmail asked for something that the users could manage themselves via a .forward (copy of email to blackberry or other wireless device account on demand on ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: mmdf mail delivery .forward file with backslash

  1. mmdf mail delivery .forward file with backslash

    Recently, a client site with mmdf for whom all email is pulled in
    with fetchmail asked for something that the users could manage themselves
    via a .forward (copy of email to blackberry or other wireless device
    account on demand on their own) - since they were already using webmin,
    i added in usermin with which they can manage a .forward from a gui (they
    can not use editor or be trusted to do anything technical).

    the problem is that with usermin, when they check the box to keep a copy
    for original receving user, usermin puts a backslash in front of username
    in the .forward.

    e.g. - if joe wants his email to go to joe and joe2, using the usermin
    gui would setup a .forward with:
    \joe
    joe2

    i do not know if this is a bug in usermin or just something that mmdf can
    not handle, but with that backslash in the username, mmdf eats up all CPU
    cycles and processes until finally failing with fork failed - too many
    processes. take the backslash out and it is fine. i've never put a
    backslash in myself when setting up .forward with vi so i'm not sure whose
    bug it is.

    --
    -Joe Chasan- Magnatech Business Systems, Inc.
    joe - at - magnatechonline -dot- com Hicksville, NY - USA
    http://www.MagnatechOnline.com Tel.(516) 931-4444/Fax.(516) 931-1264

  2. Re: mmdf mail delivery .forward file with backslash

    In article <20080318122305.A11328@magnatechonline.com>,
    Joe Chasan wrote:
    >Recently, a client site with mmdf for whom all email is pulled in
    >with fetchmail asked for something that the users could manage themselves
    >via a .forward (copy of email to blackberry or other wireless device
    >account on demand on their own) - since they were already using webmin,
    >i added in usermin with which they can manage a .forward from a gui (they
    >can not use editor or be trusted to do anything technical).
    >
    >the problem is that with usermin, when they check the box to keep a copy
    >for original receving user, usermin puts a backslash in front of username
    >in the .forward.
    >
    >e.g. - if joe wants his email to go to joe and joe2, using the usermin
    >gui would setup a .forward with:
    >\joe
    >joe2
    >
    >i do not know if this is a bug in usermin or just something that mmdf can
    >not handle, but with that backslash in the username, mmdf eats up all CPU
    >cycles and processes until finally failing with fork failed - too many
    >processes. take the backslash out and it is fine. i've never put a
    >backslash in myself when setting up .forward with vi so i'm not sure whose
    >bug it is.


    It's a common syntax for .forward files, and one which MMDF didn't understand.
    I can't reproduce the gone-haywire behavior you see, but it wouldn't work
    regardless; the expected behavior for MMDF is for \foo to be treated as an
    unknown user. Other MTAs use a leading backslash in an alias to mean that the
    alias shouldn't be recursively expanded. MMDF's syntax for this is a leading
    '~', but it doesn't need that to know that a user named in their own .forward
    file means that mail should also be delivered to that user's local mailbox.

    Since this is a general problem with users used to other MTAs and tools
    designed for other MTAs, I've modified the relevant MMDF component (submit) to
    treat a leading \ in a .forward file alias in the same way that it treats '~'.
    You can pick up a new submit binary at:

    ftp://ftp.armory.com/pub/admin/mmdf/submit

    This should replace /usr/mmdf/bin/submit, with permissions set identically to
    the current submit (setuid mmdf, etc.) I've tested this on OSR5. I'd expect
    the same binary to work properly under OSR6, but be extra careful there. Under
    OSR5, don't try to use this unless you have MP5 installed. Be sure to save the
    current submit and be ready to restore it if any problems show up. If you do
    have any problems, please let me know. This will probably appear in a
    supported form in the next MP for each OS.

    John
    --
    John DuBois spcecdt@armory.com KC6QKZ/AE http://www.armory.com/~spcecdt/

  3. Re: mmdf mail delivery .forward file with backslash

    Joe Chasan wrote:
    > Recently, a client site with mmdf for whom all email is pulled in
    > with fetchmail asked for something that the users could manage themselves
    > via a .forward (copy of email to blackberry or other wireless device
    > account on demand on their own) - since they were already using webmin,
    > i added in usermin with which they can manage a .forward from a gui (they
    > can not use editor or be trusted to do anything technical).
    >
    > the problem is that with usermin, when they check the box to keep a copy
    > for original receving user, usermin puts a backslash in front of username
    > in the .forward.
    >
    > e.g. - if joe wants his email to go to joe and joe2, using the usermin
    > gui would setup a .forward with:
    > \joe
    > joe2
    >
    > i do not know if this is a bug in usermin or just something that mmdf can
    > not handle, but with that backslash in the username, mmdf eats up all CPU
    > cycles and processes until finally failing with fork failed - too many
    > processes. take the backslash out and it is fine. i've never put a
    > backslash in myself when setting up .forward with vi so i'm not sure whose
    > bug it is.
    >


    Other folks have explained what it means. You should be able to edit usermin
    to handle your needs for MMDF. But does your client need to use MMDF? I have
    to admit that I've been walking through the SCO OpenServer configuration tools
    for it and find them loathsome. Sendmail seems reasonably well supported, both
    for SCO systems and in general.

+ Reply to Thread