home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / bit / listserv / jnetl / 103 < prev    next >
Encoding:
Text File  |  1992-08-28  |  1.7 KB  |  40 lines
  1. Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
  2. Path: sparky!uunet!paladin.american.edu!auvm!PSUECL.BITNET!CRW
  3. X-Envelope-to: JNET-L@BITNIC.BITNET
  4. X-VMS-To: JNET-L@BITNIC.BITNET
  5. Message-ID: <6E8ACD4C00C08B11@ecl.psu.edu>
  6. Newsgroups: bit.listserv.jnet-l
  7. Date:         Fri, 28 Aug 1992 15:25:00 EST
  8. Sender:       BITNIC JNET-L List <JNET-L@UGA.BITNET>
  9. From:         "Craig R. Watkins" <CRW@PSUECL.BITNET>
  10. Subject:      Re: problem with jan_receive area and quotas
  11. Lines: 27
  12.  
  13. The real problem to deal with here (in the design of a scheme) is what
  14. to do with files which are received for users that are over their quota.
  15.  
  16. Simply discarding them is not acceptable to me, but may be to some.
  17.  
  18. There's no really good way of returning them, like there is with mail.
  19. (This is because mail is text-based with the allowable syntaxes to do
  20. the job while NJE files could be binary data or executables, etc.)
  21.  
  22. You could just return it to the sender, from POSTMAST, but that's not
  23. very intuitive and wouldn't say who the bounced user was (assume the
  24. sender had sent multiple copies).
  25.  
  26. Returning the file from the (non)receiving user would certainly be confusing.
  27.  
  28. One possibility is to discard the file and send a mail message from POSTMASTER
  29. to the sender explaining the fate of the file, but that could still result
  30. in the data from the file being lost.
  31.  
  32. I guess one could return the file AND a separate mail file describing the
  33. situation.  I suspect that the file server maintainers of the network would
  34. be thrilled with this solution!
  35.  
  36. Another approach is saving the over-quota file in a special management
  37. directory for delivery later, but that's basically the way it is now.
  38.  
  39. Maybe someone has a new solution to this problem.
  40.