We've been off the  air for several days due to a  PTT problem. We're now
back on FRORS12 - the era of FRORS31 is over, and the network seems twice
as fast  from the new  vantage. Messages  come in in  blocks of 10  or so
instead of *beep* 2 messages... wait  2 seconds *beep* 2 messages... etc.
Unfortunately this also  means a V1 to V2.1 connection  that doesn't work
as well as it  might: sometimes a file gets rejected  and the line drops.
Well I just hope this won't happen too often.
 
I've been getting tons of mail  in my reader about this RFC822 extension.
I think it's a very good idea,  but I'm very pessimistic about the number
of sites  that will upgrade their  mailers. And what about  the Crosswell
mailer?
 
I definitely think that the  process generating the rejection mail should
try to  identify (as best  as possible) the source  of the error.  Now we
don't need to  get into too many  details. We just have to  look at these
errors from the point of view  of the program receiving the error notice.
Errors fail into several categories:
 
- System  error. The  mailer ran  out of  disk space,  got an  addressing
  exception, beer has  been poured in the  CPU, etc. The mail  may or may
  not be processed correctly if re-submitted.
 
- Link error. A  network line is down and prevents  mail from being sent.
  This is  from UUCP/ARPA mailers only.  The number of days  mail will be
  retried  (and suchlike)  should be  provided in  program-readable form.
  Mail should  not be re-submitted  (unless the countdown  indicates mail
  has been purged).
 
- Syntax error. Mail  is invalid and cannot be processed.  No use sending
  back.
 
- Unknown    (remote)   recipient.    Mail    syntax    is   valid    but
  domain/node/whatever is  unknown. A program-readable indication  of the
  failing address, and  whether or not this is a  permanent condition (ie
  'not in the tables' as opposed  to 'names server down, cannot determine
  the routing') should be provided.
 
- No such local user. See above.
 
- Error distributing to local user (eg disk quota exceeded).
 
And maybe  some more. The  error should be  identified in similar  way to
BSMTP errors:
 
Error-Code: <seqno> <errcode> <optional positional parms>
Error-Text: <seqno> <text>
 
Example:
 
Error-Code: 1 235 ZOZO@FRECP11
Error-Text: 1 No such local user - ZOZO.
Error-Code: 2 236 SYSTEM@FRECP11
Error-Text: 2 Mail to SYSTEM is not allowed.
 
The 'seqno'  is here only because  RFC822 does not force  mailers to keep
RFC822 fields in the order in which they were mentioned. Thus a mailer on
the path might mess the header into:
 
Error-Code: 1 235 ZOZO@FRECP11
Error-Code: 2 236 SYSTEM@FRECP11
From: daemon! <[log in to unmask]>
Error-Text: 2 Mail to SYSTEM is not allowed.
Error-Text: 1 No such local user - ZOZO.
 
  Eric