netinfo%garnet.Berkeley.EDU@violet.berkele (Postmaster & BITINFO) (11/16/87)
I have noticed at least one mail gateway for a UUCP zone domain name that does not do domain to uucp address conversion, but expects the non-domain name address mail transport agents down the line to be able to interpret domain names. Please, if you are setting up a mail exchanger (MX) entry in an Internet domain server, remember that your mail gateway is also responsible for doing any needed address conversion. Bill Wells postmaster@jade.berkeley.edu
OWENSJ%VTVM1.BITNET@MITVMA.MIT.EDU (John Owens) (11/17/87)
>I have noticed at least one mail gateway for a UUCP zone domain name that >does not do domain to uucp address conversion, but expects the non-domain >name address mail transport agents down the line to be able to interpret >domain names. Please, if you are setting up a mail exchanger (MX) entry >in an Internet domain server, remember that your mail gateway is also >responsible for doing any needed address conversion. Please be more specific about what you expect to happen, and what you're seeing. If, as I suspect, you're seeing the Internet->UUCP gateway leave the From: address in a pure domain form, then what the gateway is doing is (arguably) correct. The standard which most of the UUCP gatewaying world tried to conform to, RFC 976, specifies that the headers within the message should always remain in domain, @, form, and that only the *envelope* (the arguments to the rmail command, or the address in an SMTP RCPT TO:<...>) should be modified by the gatewaying system to adapt to network transport considerations. The receiving (UUCP) site is expected to be able to interpret domain addresses; there is widely available public domain software to do this.... There are a number of reasons that this is somewhat controversial: 1- Many mail installations set up between the advent of sendmail and the general acceptance of RFC976 would rewrite header addresses (in violation of RFC822), doing such things as prepending hostname!, creating hybrid addresses (a!b!c%d@e), etc. Many of these hosts still do so. 2- There are a large number of UUCP sites that have not installed any domain-handling software, but use programs like Berkeley Mail or System V mailx which use the From: field instead of the UUCP From_ line to reply to messages; these sites cannot reply to a pure domain address. 3- Some gateways do not agree with RFC976, preferring to use something that is more likely to work, namely rewriting addresses coming from the Internet from user@do.ma.in to gateway!do.ma.in!user, which is what you (Bill) seem to prefer. This doesn't always work, anyway, since some intermediate UUCP sites will not prepend their hostname (either they follow RFC976 or they are a truly pure UUCP site - no sendmail), and others will (sites with sendmail using the configuration file provided with the system). What I and others see as the solution is for gatewaying sites to leave addresses alone coming from the Internet to UUCP, leave addresses coming from UUCP to the Internet that are already in domain form alone, and to only change pure bang addresses coming from UUCP to the Internet, either by appending the gateway domain (host!user@gateway.org), stripping the bang path down to the last two components and turning them around to avoid hybrid addresses (user%host.UUCP@gateway.org for host!user or user%do.ma.in@gateway.org for do.ma.in!user). A variant of the latter is to turn do.ma.in!user into user@do.ma.in, and only add the gateway domain for the host!user case. All but the first of these can be dangerous, however, if the message has passed through too many gateways that have rewritten the address in too many different ways. If everyone that forwards mail via UUCP and runs sendmail, Internet gateway or not, would adopt RFC976 (and use programs like smail to help in this), we wouldn't have this mess. Since this isn't going to happen any time soon, we just have to live with it as best we can. -John Owens Virginia Tech Communications Network Services OWENSJ@VTVM1.BITNET owens@vtopus.cs.vt.edu +1 703 961 7827 john@xanth.UUCP P.S. For those of you who aren't confused enough yet :-), here's an example of the problems caused by the incompatibilities. I saw this address recently in a mailing list: From: Tom Allebrandi <unipress!ta2%edison.ge.com@rutgers.edu> This originated as From: Tom Allebrandi <ta2@edison.GE.COM> and was sent to info-ibmpc@simtel20.arpa via UUCP: rmail unipress!rutgers!simtel20.arpa!info-ibmpc Unipress, running a vanilla 4.2BSD sendmail.cf, prepended its address, giving From: Tom Allebrandi <unipress!ta2@edison.ge.com> which is already ambiguous. Rutgers, when sending it to the Internet, converted the @ to a % and added its domain, giving the address seen in the list. If USER@HOST.ARPA replied to this address, the message would go to rutgers.edu, which would most likely convert the % to an @ and give it precedence, then send to unipress!ta2 at edison.ge.com via UUCP: rmail unipress!edison!unipress!ta2 From: Joe User <USER@HOST.ARPA> Unipress again prepends its address, giving rmail edison!unipress!ta2 From: Joe User <unipress!USER@HOST.ARPA> Edison, since it runs smail and sees that the mail is just passing through, leaves it alone and sends it on to unipress!ta2. When unipress sees rmail ta2 the mail fails. In this example, the failure message would get back to the originator, but it is easy to find situations where it wouldn't and would end up in the mailbox of some postmaster somewhere, or, worse, in the "uucp" user's incoming mailbox on a system without an observant administator....