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