home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!usc!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!lll-winken!telecom-request
- From: jsweet@irvine.com (Jerry Sweet)
- Newsgroups: comp.dcom.telecom
- Subject: Re: MCI Mail Continues to Dump Incoming Mail
- Message-ID: <telecom12.904.2@eecs.nwu.edu>
- Date: 14 Dec 92 01:16:48 GMT
- Sender: Telecom@eecs.nwu.edu
- Organization: TELECOM Digest
- Lines: 26
- Approved: Telecom@eecs.nwu.edu
- X-Submissions-To: telecom@eecs.nwu.edu
- X-Administrivia-To: telecom-request@eecs.nwu.edu
- X-Telecom-Digest: Volume 12, Issue 904, Message 2 of 14
-
- I had the same problem with MCI Mail a year or two ago when I was
- maintaining a bunch of OSI-related lists. Also had a similar problem
- with ATTMail addresses. Ever attempt to contact someone in charge of
- ATTMail? Forget it. NRI, which runs the Internet-MCI Mail gateway,
- at least responded when I asked them a question about the problem.
-
- So I solved my particular problem by writing a script that uses two
- separate mailing lists: "naughty" addresses and "nice" addresses. The
- "naughty" addresses get e-mail sent to each address individually.
- It's a definite added burden on the mailhost, but them's the breaks.
- The "nice" addresses get bundled mail, as usual.
-
- I'd be happy to send the script to you if you wish. It's written in
- perl, and is designed to do deal with a list setup significantly
- different from yours, but it can at least provide an example.
-
-
- [Moderator's Note: See my reply above. I am not going to inconvenience
- my hosts here further by requiring them to handle the mail in this
- way. The simplest answer is to simply cut off the commercial sites
- which can't conform. Delivery of Internet Digests to commercial
- services is a very grey area anyway where the rules are concerned. I
- do it as a convenience for people who prefer to receive the Digest at
- those services; I do not do it so MCI/ATT can make money handling my
- (otherwise) non-profit trafic. PAT]
-