One of our biggest concerns is that the company might go out of
business.  Does anyone know how secure Software.com, Inc. is?  We
could avoid this problem by installing sendmail version 8 instead, but
post.office looks like it will be much easier to manage.

You can reply either via e-mail or to this news group.

My general opinion is that nothing that I have seen can really compare
with version 8 sendmail.  Not for security, not for message throughput,
not for reliability.

Of all the programs that are available today, sendmail is probably one of
the longest-lived, if not the longest-lived.  There are special-purpose
programs that can exceed the capabilities of version 8 sendmail in very
restricted areas (for example, smap is much more secure, but you wouldn't
want to run smap as an alternative to sendmail everywhere, instead you run
smap in addition to sendmail).

But nothing else has had anything like the debugging experience of
sendmail -- 90% of the Internet pounding on a program non-stop for years
and years is a testing environment no one else can come close to
achieving.  And I'd say that the quality of the code (and the product
thereof) reflects this fact.

What you need to do is size your resources to your requirements.  It may
very well turn out that post.office does more than you'll ever need, or it
may be that they can't meet your simplest requirements.  You need to take
a hard look at the alternatives and make whatever decision you make with
full information.

--
Brad Knowles, comp.mail.sendmail FAQ Maintainer      b...@his.com
             The comp.mail.sendmail FAQ is located at:
  <ftp://rtfm.mit.edu/pub/usenet/news.answers/mail/sendmail-faq>

        What is the motivation?

: could avoid this problem by installing sendmail version 8 instead, but
: post.office looks like it will be much easier to manage.

        I'm pretty sure that, while once installed, sendmail doesn't require
        any more management.

: You can reply either via e-mail or to this news group.

: Thanks
: ----------------------------------------------------------------------
: Haim (Howard) Roman     |  Computer Center
: ro...@brachot.jct.ac.il |  Jerusalem College of Technology,  ISRAEL

--

        With best regards -- Andrew Stesin.

        +380 (44) 2760188       +380 (44) 2713457       +380 (44) 2713560

Example: I have successfully added a File|Launch Schedule+ command to my
MSMail pull-down menu. This is very convenient. I would like to do the same
thing for Schedule+ to launch MSMail.

        I found the procedure to add this stuff to MSMail in the technical
manual that came with MSMail. Is there a similar resource for the Schedule+
that comes with WFW3.11? Or, do any of you know how to do this, or where to
find the info.? Hope you can help. Thanks!!!!  :)

We have a strange requirement of defining a mail alias combining two mailing
lists, such that any mail sent to this mail alias would reach to the members
of both the mailing lists. Now, we have a problem with "Reply-To:" field.

In the mails sent to the mail alias reaches both the list, but the Reply-To:
field in each of the mailing lists appear with the individual mailing list's
address, whereas, what we want it to be set to the mail alias address, so that
any one's response to this mail in any of the mailing lists, should appear
to both the mailing lists. Hope I have been clear.

Do you guys have any quick solutions ? One thing, I can think of, is to
create a user-account, instead of mail alias, and having a .forward file
to process the headers (basically adding Reply-To: field) and then sending
it to both the mailing lists. In this case, do I have to invoke the
sendmail for this mail to be sent without distrubing the headers ? We want
any post sent to this mail alias to appear with the From: field showing the
originator's  e-mail address, but Reply-To: must be set to the alias that
combines both the mailing lists.

I appreciate *any* solutions. Thanks in advance !!

I think that my 'kehlist' can do that.

(I have posted that to alt.sources under Archive-name: kehlist0103/* )

#!/bin/sh
cat > kehlist.README <<'EOM'

Kehlist is simple(?) filter to implement mailing list.
You can implement mailing list by using sendmail's
aliases, but that way replies to mail, which comes
from list, goes to sender.

Kehlist adds or modifies Reply-To: header that way,
that replies to mail goes to list. Or alternatively kehlist
leaves Reply-To: header intact and adds or modifies
Wide-Reply-To: header so group replies to mail goes
to list (see: group reply mode).

Kehlist can decode base64 and quoted-printable
content-transfer-encodings to 8bit encoding.
Kehlist avoids decoding base64 content-transfer-encoding
if charset is something odd (for example UNICODE-1-1).
It also can code 8bit content-transfer-encoding to
quoted-printable encoding. Kehlist cancels decoding of
quoted-printable or base64 encoding if resulting part
will be binary content-tranfer-encoding (ie. when resultting
text have too long lines transformation is not done).
Kehlist also considers content of part to be binary
if it includes nul characters.

Kehlist also allow to split list so several sublists,
which acts together as one list.

Kehlist does NOT process automatically subscribe or
unsubscribe requests.

Usage: ./kehlist [-d] [-f0] [-g] [-r] [-p] [-b] [-e] [-M MAILER-DAEMON] [-f] [-U UUCP] [-D DNET] [-C] [-P List] bumerang address-list list-name [full-name]
       ./kehlist [-d] [-f0] -F config-file

Put the following aliases to sendmail aliases file:
my-list: "|/path/kehlist my-list-request /path/list_addresses my-list 'My funny list'"
my-list-request: myname

or

my-list: "|/path/kehlist -F /path/my-list.config"
my-list-request: myname

If you call kehlist from .forward -file, take care that that user
(which owns that .forward file) have merked as 'trusted' user in sednmail.cf.

And put to file my-list.config:
List-name:              My funny list
List-address:           my-list
Bumerang-address:       my-list-request
Address-file:           list_addresses
#Following are defaults:
Insert-Resent-headers:  False
Drop-Resent-headers:    False
Private-List:           False
Allow-Bumerang:         False
Insert-Errors-To:       False
Mailer-Daemon:          MAILER-DAEMON
Use-From:               True
Accept-UUCP:            False
UUCP-Domain:            UUCP
Accept-DECNET:          False
DECNET-Domain:          DNET
Convert-Message:        True
Precedence:             List
Set-Precedence:         False
Add-Host-Name:          False
Group-Reply-Mode:       False
Process-Return-Receipt-To:              True
List-Receiver-Mode:     NIL

list_addresses file can include, for example:

Kari.Hur...@Fmi.Fi = hur...@dionysos.fmi.fi
QP: some.user@somewhere
# This user can't decode quoted-printable yourself
8BIT: some.other.user@somewhere

It can also include
DEBUG: My.Name@somewhere
LIST: My funny list <list_addresses2> = my-list-request

(no - I _don't_ really like to be in every possible mailing list!!)

Syntax of address file is same as sendmail's :include: files except
that = indicates alias addresses of subscriber and before address
there can be 'mode:' where mode is one of NIL, 8BIT, QP.
Mode can be also be one of DEBUG and LIST. First address is
that to what addresses postings to list are sent. Addresses after =
are used to see, if address of envelope sender is in list.
Character # indicates that rest of line is comment. If want use characters
# and = in addresses, put address inside of < >.

Mode tells which transformations for MIME body-parts must do: NIL means
no transformations, 8BIT means transformation from quoted-printable
to 8bit (this is doen only for subtypes of 'text' -type, sometimes
kehlist may unintionally produce trabsformation quoted-printable
to binary - this isn't prevented as it should), QP means transformation
from 8bit (or binary) to quoted-printable. Krhlist don't handle
base64 encoding.

Receivers of mode DEBUG get one copy of all envelopes, which kehpager
sends.

Receivers of mode LIST have sublists (or parent lists). Format for that is:
  LIST: List Name <list1@machine> = <list1-request@machine>
Actual mode of mode LIST can tell in config file with:
  List-Receiver-Mode:   NIL
or
  List-Receiver-Mode:   QP
or
  List-Receiver-Mode:   8BIT

If listaname1 have receiver:
  LIST: List Name <listname2@machine> = <listname2-request@machine>
Then listname2 must be receiver:
  LIST: List Name <listname1@machine> = <listname1-request@machine>
Otherwise kehlist bounces mail with configuration error.

When mail comes from sublist, kehlist replaces address of sublist in
Reply-To: and Wide-Reply-To: headers with address of list.

Notice that pipes in aliases file are run under sendmail's default uid
(which is normally 1). (At least, when using sendmail 8.6.X)

Subcribers can be one per line or they can be seperated by comma (,).
If in address have = or : characters, but address inside to < > braces
(if that part of address isn't already quoted).

Kehlist send incoming mails to all subscribers EXCEPT to (envelope) sender. If
sender wanna copy of letter, he can add header
        X-kehlist-copy: sender@address
to mail. In group reply mode kehlist scans To:, CC:, Resent-TO: and Resent-CC:
header for receivers and avoids sending mail to these receivers (this CAN'T
be overrided with X-kehlist-copy).

Kehlist modifies Reply-To: header following way:
        1) Adds address of list to beginning of Reply-To line
        2) Removes list members from Reply-To line
        3) Adds address(es) from From line to Reply-To line, if
                address wasn't member of list _and_ there wasn't Reply-to
                line originally. If using of From -header is disabled
           then kehlist uses envelope sender instead.
        4) X-kehlist-copy addresses are also added to Reply-To line
                (if they didn't member of list)

If envelope sender isn't member of list, kehlist adds X-kehlist-notice
header, which tell that fact, to mail. That is done, that it is easy
notice, if some envelope sender addresses is missing from list (envelope
sender is easy add as alias to subscribers list by using '=' -syntax).

Return-Receipt-To header generates delivery raport from kehlist if
in config file have NOT line:
  Process-Return-Receipt-To:            False
Return-Receipt-To headers are removed.

Kehlist removes any Errors-To:, Content-Lenght:, Return-Receipt-To:
and Return-Path: headers from mail.

Option -p or line
Private-List:           True
in config file, causes that kehlist requires that enevelope sender
is member of list (bumerang anddress should be fully qualified in this
case, because it is mentioned in kehlist's error message. For example:
Bumerang-address:       my-list-requ...@my.domain
)

Option -r or line
Insert-Resent-headers:  True
in config file, causes that kehlist adds Resent-* headers to mail
(list address should be fully qualified, bacuase domain of list address
 is used in message-id (header Resent-Message-ID). For example:
List-address:           my-l...@my.domain)
Kehlist also adds Resent-* headers when there already was some Resent-*
header mail in mail, even when config file reads:
Insert-Resent-headers:  False
To avoid completely creation of Resent-* headers, add to config file:
Drop-Resent-headers:    False

Drop-Resent-headers:    False
in config file, causes that all old Resent-* headers are dropped from mail.
This also drops old X-List-Processor: and X-kehlist-notice: headers from mail.

Option -b or line
Allow-Bumerang:         True
in config file, causes that mail's with null envelope sender (or where
envelope-sender is MAILER-DAEMON) isn't rejected. Normally kehlist rejects
these mail to avoid mail loops (what can happend if list is misconfigured).

With option -M <mailer-daemon name> or line
Mailer-Daemon:          <mailer-daemon name>
in config file, changes which address is treated as null sender.
This address should match to name in 'Dn' -line in (local) sendmail.cf.

Option -e or line
Insert-Errors-To:       True
in config -file, causes that kehlist adds Errors-To -header line to mail.

Option -f or line
Use-From:               False
in config -file, causes that kehlist uses envelope sender in
Reply-To or Wide-Reply-To -line (instead of addresses in From -line).

With option -U <UUCP-Domain> or lines
Accept-UUCP:            True
UUCP-Domain:            <UUCP-Domain>
in config -file, kehlist parses host!user form from "From " -line
(and in headers of mail).  If in host haven't damain appended
(ie. no unquoted '.') then, kehlist appends <UUCP-Domain> to that
(with '.').  That address is domainized to RFC 822 form.
Kehlist don't handle UUCP bang-paths.

With option -D <DECNET-Domain> or lines
Accept-DECNET:            True
DECNET-Domain:            <DECNET-Domain>
in config -file, kehlist parses host::user form from "From " -line
and in headers of mail.  If in host haven't damain appended
(ie. no unquoted '.') then, kehlist appends <DECNET-Domain> to that
(with '.').  That address is domainized to RFC 822 form.
If Accept-DECNET is false, kehlist confuses Decnet addresses with
RFC 822 group syntax (Group syntax uses one : -character after phrase).

Option -C or line
Convert-Message:        False
in config -file, puts transparent mode. In that mode conversions for
MIME-messages isn't done. Also in transparent mode kehlist don't use
temporary files. Header
        Content-Conversion: Prohibited
in message also puts kehlist to transparent mode.      
Notice that this severely limits of functionality of kehpager (when
kehpager don't use temporary files, kehpager can't consume mail
several times).