FirstClass has a bug in it's SMTP software that does not return mail to
port-mac68k, but to everybody on the list. (being port-mac68k).
i remember a few months ago i was a Majordomo newbie and was complaining
about receiving TONS AND TONS of warning about unsuccessful delivery of
messages. that happened because i was sending mail to
port-mac68k-owner@netbsd.org.
After using port-mac68k@netbsd.org, the warning messages were stopped (and
were being sent back to the majordomo, either read or ignored by whoever
runs the list. you must be wasting a LOT of time reading the warnings, :-)
well, later on, i noticed that every time i sent mail to
port-mac68k@netbsd.org, i would always get a returned mail message from a
FirstClass gateway somewhere on the net, about not being able to deliver
because the mailbox was full. It wasn't supposed to send it to me, but the
majordomo program.
well, FirstClass is back! it's not sending the mail to the individual that
sent the mail, but the entire mailing list, port-mac68@netbsd.org! the mail
is continually pinged back here, as error messages, not being able to
deliver the mail, since the sysadmin has set his mail retry delay to be
three or four minutes or so (BAD mistake)....i think we ought to pat the
stupid sysadmin who did that. then again, maybe FirstClass users should be
encouraged not to subscribe to mailing lists for that stupid mailing error,
anyway.
this may also be a bug of the FirstClass UUcp gateway, too.
don't jump to conclusions, i may be wrong, and i *think* this is the case.
it's a fault of the FirstClass software, definately, along with some
sysadmin problems (maybe).
just be patient, i guess. the sysadmin of Maple_FC_Gateway will notice
eventually that his system is sending out tons of mail...
btw, most FirstClass system administrators can be reached at administrator@
and sysop@. so flame away.
have fun, and i'll be hitting that delete key all afternoon....
  - a

>Well, if this were sendmail, it would have sent the warning message after
>having tried to send the original message for four hours.  But, sendmail
>would only have sent the warning message _once_ instead of after each and
>every delivery attempt!
>
>One more reason not to use qmail?  (No flames, please, I'm really not
>trying to start that discussion again!  :)
>
>On Sat, 30 Nov 1996, Tristan Doherty wrote:
>
>> I am getting this too! When I checked my mail this morning when I checked
>> my mail, I got in excess of fifty messages. It seems that the subject line
>> "Warning: could not send message for past 4 hours" should more acurately
>> say "for past 4 minutes", because that looks like it is about the time
>> between each message sent.
>>
>> Here is a transcript of the messages I received:
>>
>> Date: Sat, 30 Nov 1996 21:58:09 +0900 (JST)
>> From: Maple_FC_Gateway <fcgate@leaf.maple.or.jp>
>> To: port-mac68k@NetBSD.ORG
>> Subject: Warning: could not send message for past 4 hours
>> Sender: port-mac68k-owner@NetBSD.ORG
>> Precedence: list
>> Delivered-To: port-mac68k@NetBSD.ORG
>>
>> This is a MIME-encapsulated message
>>
>> --TAA26373.849349286/leaf.maple.or.jp
>>
>> The original message was received at Sat, 30 Nov 1996 15:04:24 +0900 (JST)
>> from fcgate@localhost
>>
>>    ----- The following addresses have delivery notifications -----
>> news@maple-gw.maple.or.jp  (transient failure)
>>
>>    ----- Transcript of session follows -----
>> news@maple-gw.maple.or.jp... Deferred: Connection reset by peer with
>> maple-gw.maple.or.jp.
>> Warning: message still undelivered after 4 hours
>> Will keep trying until message is 5 days old
>>
>> --TAA26373.849349286/leaf.maple.or.jp
>> Content-Type: message/delivery-status
>>
>> Reporting-MTA: dns; leaf.maple.or.jp
>> Arrival-Date: Sat, 30 Nov 1996 15:04:24 +0900 (JST)
>>
>> Final-Recipient: RFC822; news@maple-gw.maple.or.jp
>> Action: delayed
>> Status: 4.2.0
>> Remote-MTA: DNS; maple-gw.maple.or.jp
>> Last-Attempt-Date: Sat, 30 Nov 1996 19:21:26 +0900 (JST)
>> Will-Retry-Until: Thu, 5 Dec 1996 15:04:24 +0900 (JST)
>>
>> --TAA26373.849349286/leaf.maple.or.jp
>> Content-Type: message/rfc822
>>
>> Return-Path: fcgate
>> Received: (from fcgate@localhost) by leaf.maple.or.jp (8.7.5/8.7.3) id
>> PAA05123; Sat, 30 Nov 1996 15:04:24 +0900 (JST)
>> Date: Sat, 30 Nov 1996 15:04:24 +0900 (JST)
>> Message-Id: <199611300604.PAA05123@leaf.maple.or.jp>
>> From: yama@radical.biotech.okayama-u.ac.jp (Mamoru Yamanishi)
>> To: news@maple-gw.maple.or.jp
>> Subject: Re: booting on 630!!
>> X-FC-Conference: local.maple.port-mac68k
>>
>> I will add additional informations.
>>
>> > Results         Performa630                     Quadra630
>> >
>> > kernel
>> > netbsd.quadra   boot,
>> >                 but it makes core dump          not tested
>> >                 when the monitor is 832 x 624
>> >                 black&white mode.
>> >                 (other modes are not tested)
>>
>>                   It takes "segmentation fault" and core-dumped.
>>                   At these case, syslog.core and mount.core are made.
>>                   While core dumps, booting reached "login", and
>>                   some of commands can work.  "ls" work, but "ls -l"
>>                   make core dump.
>>
>> > I found some problems;
>> >         on both case, it cannot beep.
>> >         it cannot turn power off by itself when shutdown.
>> >         time seems correct, but error message appears.
>>
>> The followings are boot messages on Quadra630/GENERIC-12.
>>
>> NetBSD 1.2B (GENERIC) #12: Tue Nov 19 23:30:07 CST 1996
>>     scottr@spot:/usr/src/sys/arch/mac68k/compile/GENERIC
>> Apple Macintosh Quadra 630  (68040)
>> real mem = 37748736
>> avail mem = 33689600
>> using 204 buffers containing 835584 bytes of memory
>> mrg: 'Quadra630 ROMs' ROM glue, tracing off, debug off, silent traps
>> mrg: I/O map kludge for ROMs that use hardware addresses directly.
>> adb: bus subsystem
>> adb: unknown type device, (def 1, handler 43) at 1
>> adb: keyboard at 2
>> adb: 200 dpi mouse at 3
>> mainbus0 (root)
>> obio0 at mainbus0
>> adb0 at obio0 (ADB event device)
>> asc0 at obio0 Apple sound chip.
>> esp0 at obio0: address 0x8ff000: NCR53C96 16Mhz, target 7
>> scsibus0 at esp0
>> sd0 at scsibus0 targ 0 lun 0: <QUANTUM, LP240S GM240S01X, 6.4> SCSI2
>> 0/direct fixed
>> sd0: 234MB, 1818 cyl, 4 head, 65 sec, 512 bytes/sec
>> cd0 at scsibus0 targ 3 lun 0: <MATSHITA, CD-ROM CR-8004, 1.1f> SCSI2
>> 5/cdrom removable
>> zsc0 at obio0 chip type 0
>> zstty0 at zsc0 channel 0
>> zstty1 at zsc0 channel 1
>> fpu0 at obio0 (mc68040)
>> nubus0 at mainbus0
>> root on sd0a swap on sd0b
>> PRAM time does not appear to have been read correctly.
>> PRAM: 0x83da807e, macos_boottime: 0x32a04368.
>> savecore: no core dump
>>
>> The PRAM problem dues to the GMT bias on Botter, I think?
>>
>> Mamoru
>>
>>
>> -------------------------------------
>> Mamoru Yamanishi <yama@radical.biotech.okayama-u.ac.jp>
>> +81-86-251-8196(voice), +81-86-253-7399(GIII fax)
>> Dept. Biotechnology, Okayama Univ.
>>
>>
>>
>> --TAA26373.849349286/leaf.maple.or.jp--
>>
>>
>> ------------------------------------------------------
>> Tristan Doherty                      ristar@abacom.com
>>
>>
>>