jjones@andrew.ATL.GE.COM (Jeffrey Scott Jones) (10/16/90)
We have a mixed environment of Ultrix and VAX/VMS systems here, and we exchange a lot of mail between these systems. I have configured our installation of MH to use sendmail (no SMTP). The problem that I am having is when my friends in VMS land send a mail message to me on Ultrix, the message format is in DECNet format. The mail header is not received by MH from sendmail in a normal header format (it is in DECNet format). So, when I attempt to reply to the message, MH fails to assemble the return address. I sent a message to myself with the To: line saying: To: jjones@atl.dnet here is what I got back: Return-Path: atl::FOOBAR::jjones Date: Tue, 16 Oct 90 08:12:30 EDT From: atl::FOOBAR::jjones (Jeffrey Scott Jones) To: atl::jjones Subject: test from Mail body of message FOOBAR is the name of the machine that I'm recieving mail on. I believe that the solution to this problem is to add a rule to sendmail.cf to rewrite the address on receipt from a DECNet connection, but I don't have the slightest idea of how to do this. An interesting note: I tried this exact experiment with Mail(1), and Mail has no problem dealing with the DECNet format addresses. DEC must have munged Mail(1). I don't think that was the correct choice. How have you dealt with this? ========================================================================== Jeffrey Scott Jones General Electric Senior Member, Engineering Staff Advanced Technology Labs (609)866-6538 RT 38, Bldg 145, Moorestown, NJ 08057
moore@betelgeuse.cs.utk.edu (Keith Moore) (10/19/90)
In article <329@puma.ge.com> jjones@andrew.ATL.GE.COM.UUCP (Jeffrey Scott Jones) writes: >We have a mixed environment of Ultrix and VAX/VMS systems here, and >we exchange a lot of mail between these systems. I have configured our >installation of MH to use sendmail (no SMTP). > >The problem that I am having is when my friends in VMS land send a mail >message to me on Ultrix, the message format is in DECNet format. The >mail header is not received by MH from sendmail in a normal header >format (it is in DECNet format). So, when I attempt to reply to the >message, MH fails to assemble the return address. > >I sent a message to myself with the To: line saying: To: jjones@atl.dnet >here is what I got back: > > Return-Path: atl::FOOBAR::jjones > Date: Tue, 16 Oct 90 08:12:30 EDT > From: atl::FOOBAR::jjones (Jeffrey Scott Jones) > To: atl::jjones > Subject: test from Mail > > > body of message > >FOOBAR is the name of the machine that I'm recieving mail on. > >I believe that the solution to this problem is to add a rule to >sendmail.cf to rewrite the address on receipt from a DECNet connection, >but I don't have the slightest idea of how to do this. You have the right idea in that the headers of the message should be rewritten before your mail user agent (in this case MH) sees it. Unfortunately, this is difficult to do well with sendmail rewrite rules, because: a) The rule should only apply to messages that come from your DECnet gateway, not to messages that come from other sources. Sendmail does not give you a good way to do selective rewriting based on where a message *comes from* (as opposed to mailer-specific rewrite rules for outgoing mail). IDA sendmail does a better job. b) It is difficult to translate multiple-hop DECnet addresses in a way that results in a "correct" translation that will not be munged by other sites running sendmails whose configurations violate rule (a). c) The addresses in VMS MAIL To: and CC: lines are frequently illegal in the RFC822 world. VMS MAIL accepts recipients of the form @filename and leaves them, uninterpreted, in the message header. VMS MAIL also accepts other kinds of DECnet addresses that don't even resemble the user@domain format common in the RFC822 world, but are confusing to RFC822 mail handling programs. Most sendmail config's cannot make any sense of an address like NODE::PSI%digit-string, and sendmail cannot deal with quoted strings at all. >An interesting note: I tried this exact experiment with Mail(1), and >Mail has no problem dealing with the DECNet format addresses. DEC must >have munged Mail(1). I don't think that was the correct choice. It's possible that DEC munged Mail a bit. Also, some user agents are "smarter" than others about header addresses. The stupid ones don't complain no matter what you throw at them -- they just pass it to sendmail or whatever and let it deal with them. The smarter ones justly complain about syntactically incorrect addresses. Others are in-between -- they just core-dump when you give them something besides user@domain. >How have you dealt with this? Well, I wrote my own mail11 gateways. My in-house versions of these gateways have regular-expression -based rewrite rules to deal with several kinds of addresses and intelligently coerce them into a reasonable RFC822 address. It also queries the domain name server to translate DECnet node names into Internet domain names, if such a name exists. That version isn't ready for release yet, but you can get an older version of the gateway via anonymous ftp to cs.utk.edu, directory readonly/mail11, files mail11[d].{tar,shar}. A modified version of the same gateway is available from anon ftp to gatekeeper.dec.com. (I don't remember which directory.) This version has different address translation mechanisms than my last released version. If you are not in a position to change the gateway, you might want to try compiling MH with either the DUMB or BERK options, which will make it less picky about addresses. Your mileage may vary -- MH has so many options that affect its operation in subtle ways that once upon a time, I grep-ed the entire MH source for #if, figured out exactly which set of options to use, and made that set a local standard once and for all. I don't ever want to deal with it again. (It's experiences like this that have encouraged me to work very hard on the next version of my mail-11 gateways, in the hopes that the number of options can be minimized while still allowing the gateway to work well without modification for most sites.) Keith Moore / U.Tenn CS Dept / 107 Ayres Hall / Knoxville TN 37996-1301 Internet: moore@cs.utk.edu BITNET: moore@utkvx ``Paranoia is a drug which is more dangerous than any controlled substance.''
he@spurv.runit.sintef.no (Havard Eidnes) (10/21/90)
In article <1990Oct18.220124.7784@cs.utk.edu> moore@cs.utk.edu (Keith Moore) writes: >Unfortunately, this is difficult to do well with sendmail rewrite rules, >because: > >a) The rule should only apply to messages that come from your DECnet > gateway, not to messages that come from other sources. Sendmail > does not give you a good way to do selective rewriting based on > where a message *comes from* (as opposed to mailer-specific rewrite > rules for outgoing mail). IDA sendmail does a better job. This can be circumvented by having the mail11 receiver (mail11d) call sendmail with a special configuration file only designed to rewrite DECnet addresses, and then passing the mail onwards to the real sendmail. (No, I didn't think of this myself...) - Havard
moore@betelgeuse.cs.utk.edu (Keith Moore) (10/22/90)
In article <1990Oct21.103233.7518@idt.unit.no> he@spurv.runit.sintef.no (Havard Eidnes) writes: >In article <1990Oct18.220124.7784@cs.utk.edu> moore@cs.utk.edu (Keith Moore) writes: >>Unfortunately, this is difficult to do well with sendmail rewrite rules, >>because: >> >>a) The rule should only apply to messages that come from your DECnet >> gateway, not to messages that come from other sources. Sendmail >> does not give you a good way to do selective rewriting based on >> where a message *comes from* (as opposed to mailer-specific rewrite >> rules for outgoing mail). IDA sendmail does a better job. > >This can be circumvented by having the mail11 receiver (mail11d) call >sendmail with a special configuration file only designed to rewrite DECnet >addresses, and then passing the mail onwards to the real sendmail. (No, I >didn't think of this myself...) > >- Havard Actually, I've tried this to a limited extent. I gave up because sendmail has too much code that assumes RFC822-style addresses (despite the need to do some of the parsing in the config file). For instance, for our local configuration, I wanted to translate inbound mail-11 From: lines of the form NODE::BITNET%"USER@XYZZY" into USER@XYZZY.BITNET, but there was no way to get sendmail to "break open" the quoted string without modifying C code. This technique does work pretty well for, say, handling inbound UUCP mail, where you want to interpret envelope addresses of the form a!b!c@d to mean "send to b!c@d via a", rather than "send to a!b!c via d", as when the message arrives via SMTP/TCP. The drawback is that it's bad enough to have to maintain a single sendmail.cf file, much less one for each mail channel. Keith Moore Keith Moore / U.Tenn CS Dept / 107 Ayres Hall / Knoxville TN 37996-1301 Internet: moore@cs.utk.edu BITNET: moore@utkvx ``Paranoia is a drug which is more dangerous than any controlled substance.''
jones@ut-emx.uucp (William L. Jones) (10/23/90)
I modefied the mail-11 mailer daemon to translate decnet mail address as follows: node::"hast@domain" -> host@domain node::"user" -> user@node.thenet node::user -> user@node.thenet This simplifies the sendmail configuration file a greate deal. It also make it possible for user to reply to mail messages sent form decent. The "thenet" is used only on the localhost. If the localhost is used as a mail fowarder for say internet mail by decnet then user@node.thenet gets rewritten as user%node.thenet@localhost. Bill Jones
obh@ifi.uio.no (Ole Bj|rn Hessen) (10/23/90)
In article <1990Oct22.011036.3679@cs.utk.edu>, moore@betelgeuse.cs.utk.edu (Keith Moore) writes: > For instance, for our local configuration, I wanted to translate > inbound mail-11 From: lines of the form NODE::BITNET%"USER@XYZZY" > into USER@XYZZY.BITNET, but there was no way to get sendmail to > "break open" the quoted string without modifying C code. True. Include a patch from Paul Vixie's sendmail in your favourite sendmail and there you fly. There is no way you can create a ruleset 3 that handle both DECnet addresses and RFC822 addresses (and still get a good night of sleep :-). Maintainance: The clue is to rewrite special-type addresses to RFC822 format and then pass it on to the more complex sendmail.cf file. That reduces maintainance to *very* simple sendmail.cf-files and a more complex sendmail.cf file that know how to do RFC 822 and routing. You get simplicity where you need it; and complexity in one central place, reduced to the level of understanding. I haven't pondered on my sendmail.cf files in months. > Keith Moore Ole Bjorn