steve@thelake.UUCP (Steve Yelvington) (12/08/89)
Based on John Chew's "Inter-Network Mail Guide," I recently tried to send
a note to someone whose only e-mail address is on Compuserve. BOING!
When it left my system, it was addressed like so:
To: 73607.1231@compuserve.com
From: steve@thelake.UUCP (Steve Yelvington)
Reply-To: pwcs.StPaul.GOV!stag!thelake!steve
So what happened to this mail? It bounced at hal.cwru.edu with this error
message:
----- Transcript of session follows -----
>>> RCPT To:<73607.1231@uccba.uc.edu>
<<< 550 <73607.1231@uccba.uc.edu>... User unknown: Not a typewriter
550 <uccba!73607.1231@hal.cwru.edu>... User unknown
I was fairly certain that the person to whom I had addressed the mail was
not a typewriter, and gratified to have my grip on reality verified by
hal, but I am quite confused about uccba.uc.edu and what it has to do with
Ohio-based Compuserve.
Hal very politely returned my mail intact. Then I looked at the header:
To: 73607.1231@compuserve.com
From: steve@cis.ohio-state.edu (Steve Yelvington)
Reply-To: wuarchive!swbatl!pwcs!stag!thelake!steve@mailrus.cc.umich.edu
This is the first time I've been teleported to Ohio State. Once I was
teleported to Apple Computer, which was almost as surprising.
Fingerprints were left by:
cwjcc.INS.CWRU.Edu
saqqara.cis.ohio-state.edu
tut.cis.ohio-state.edu
mailrus.cc.umich.edu
wuarchive.wustl.edu
swbatl.sbc.com
pwcs.StPaul.GOV
stag.UUCP
I regularly have mail pass through wuarchive, swbatl, pwcs and stag
without anything horrid happening.
I don't mind the rewriting of Reply-To:, since it was done correctly, but
who would ever have a good reason to rewrite the From: line?
Do I need to include X-Really-From-Before-Header-Mangling: ?
-- Steve Yelvington at the (almost frozen enough to skate) lake in Minnesota
UUCP: ... pwcs.StPaul.GOV!stag!thelake!stevekarl@giza.cis.ohio-state.edu (Karl Kleinpaste) (12/10/89)
Oh, my. What an opportunity. Yet another Domain Absolutism argument. steve@thelake.uucp writes: Based on John Chew's "Inter-Network Mail Guide," I recently tried to send a note to someone whose only e-mail address is on Compuserve. BOING! ... To: 73607.1231@compuserve.com From: steve@thelake.UUCP (Steve Yelvington) Reply-To: pwcs.StPaul.GOV!stag!thelake!steve ... >>> RCPT To:<73607.1231@uccba.uc.edu> <<< 550 <73607.1231@uccba.uc.edu>... User unknown: Not a typewriter 550 <uccba!73607.1231@hal.cwru.edu>... User unknown This part isn't my fault. That specific problem is apparently caused by a mailer at (I'm guessing here, partially) uccba or CWRU, where it somehow magically strips one item out of a !-path. We have a user here who has acquaintances at Amdahl, who were trying to reach this local person via username@cis.ohio-state.edu; they got bounces back because, by the time the mail got to here, it no longer contained any reference to Ohio State in the RCPT TO:. Something similar happened in your case. I can't explain it in detail, but it's certain that it only affects shrieky addresses (!-paths) by mis-stripping something out of them, apparently the last hostname in the shriek. Putting on my sendmail.cf debugger's hat for a moment, methinks I detect a mistyped digit in a sendmail.cf RHS, e.g., someone's $1 should have been $2, or something like that. [returned mail reads:] To: 73607.1231@compuserve.com From: steve@cis.ohio-state.edu (Steve Yelvington) Reply-To: wuarchive!swbatl!pwcs!stag!thelake!steve@mailrus.cc.umich.edu This is the first time I've been teleported to Ohio State. This one _appears_to_be_ my fault; more precisely, it's your own fault, because you apparently let it escape your system looking like "From: steve@thelake" without even ".uucp" attached, much less a real domain. We are probably going to get into a religious war here, but my side of the issue reads directly from the scriptures. RFC822, section 6.2.2., "Abbreviated Domain Specification," page 29-30, reads: When a message crosses a domain boundary, all addresses must be specified in the full format, ending with the top-level name-domain in the right-most field. It is the responsibility of mail forwarding services to ensure that addresses conform with this requirement. My sendmail configuration believes in 6.2.2 deep in its heart. The interpretation of this comment from 6.2.2 is that if you send mail which passes my way which claims to be "From: user@OneWordHostName," I'm going to commit a rudeness against it. OneWordHostNames seen outside their domain of origin are a violation of the requirement to "specif[y] in the full format," that is, you didn't supply a fully-qualified domain name (FQDN) in your From: line. Two things cause this: It is a matter of local policy that mail coming from here hides the individual hostname in favor of just the domain name, so if someone tries to specify user@SomeWorkstation, it gets rewritten as user@cis.ohio-state.edu and delivered locally; and there is no way for me to determine in what context I should interpret any OneWordHostName except as part of cis.ohio-state.edu. Please note that this occurs _only_ for user@OneWordHostName. If you're _certain_ that it left your site as "steve@thelake.uucp," then I suggest that someone else mangled it into "steve@thelake" before it got this far. I leave ".uucp" and ".bitnet" domains alone, because such hostnames qualify as FQDNs in a syntactic sense, even if the domains themselves are formally invalid, semantically. I went a few rounds on this topic around October or so regarding Pete Holzmann's machine "octopus." There is (or was) a machine octopus.cis.ohio-state.edu, and mail was coming from Pete's machine as "user@octopus" without domain qualifiers. I hope it's obvious as to the nature of the conflict this creates, and hence why 6.2.2 contains this requirement. The bottom line is: Advertise RFC-conformant addresses in your From: line in the first place, and I will happily leave it unmolested; hand me something RFC-invalid, and I'll make my own personal best guess as to how to return to RFC conformance, and you're bound to lose in the process. --Karl Kleinpaste Personification of the Mailer Daemon Ohio State Computer Science
bill@twwells.com (T. William Wells) (12/11/89)
In article <KARL.89Dec9233524@giza.cis.ohio-state.edu> karl@giza.cis.ohio-state.edu (Karl Kleinpaste) writes:
: The bottom line is: Advertise RFC-conformant addresses in your From:
: line in the first place, and I will happily leave it unmolested; hand
: me something RFC-invalid, and I'll make my own personal best guess as
: to how to return to RFC conformance, and you're bound to lose in the
: process.
You are not the only one who does this. When my mail goes through
uflorida, it turns at least some unqualified names into
user@bikini.cis.ufl.edu; imagine my mailing list members' surprise
when list mail from me appeared to come from
objectivism@bikini.cis.ufl.edu!
Here's what happens: when I send mail to a local name from this
machine, the To: line is just a local address. If that mail gets
forwarded outside the machine, the To: line is, of course, bogus.
So, if I personally sent e-mail to the list, it would go out from
here without any kind of system name on the To: line and uflorida
would rewrite it. I've put in a hack to prevent this, but I
really should arrange that all mail addresses have a system name
before they leave this system. There are probably other things
that could be done to make the headers more conformant, but that
appears to be the biggie.
I'm running smail2.5 here; has anyone heard of a fix that will
add my domain name to unqualified addresses? Sooner or later, I'm
going to have to fix this and I'd rather not reinvent the wheel.
And, while I'm at it, are there any other things that smail2.5
fails to get right?
---
Bill { uunet | novavax | ankh | sunvice } !twwells!bill
bill@twwells.competer@ficc.uu.net (Peter da Silva) (12/11/89)
In article <1107891037263761@thelake.UUCP> pwcs.StPaul.GOV!stag!thelake!steve writes: > I regularly have mail pass through wuarchive, swbatl, pwcs and stag > without anything horrid happening. Well, I've had all sorts of problems getting to sites at WU, and have gotten the most amazing bounces from wuarchive and nearby sites. I suspect that they, or someone topologically close to them, is a liberal header rewriter. Also, texbell.lonestar.org tends to create fictional From: lines. This seems to be due to a piece of excessive RFC-ishness in smail 3.0 alpha. If you ever get weird mail with my signature from texbell!Postmaster, that's what happened. -- `-_-' Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>. 'U` Also <peter@ficc.lonestar.org> or <peter@sugar.lonestar.org>. "If you want PL/I, you know where to find it." -- Dennis
chet@cwns1.CWRU.EDU (Chet Ramey) (12/12/89)
In article <KARL.89Dec9233524@giza.cis.ohio-state.edu> karl@giza.cis.ohio-state.edu (Karl Kleinpaste) writes: >steve@thelake.uucp writes: > Based on John Chew's "Inter-Network Mail Guide," I recently tried to send > a note to someone whose only e-mail address is on Compuserve. BOING! > ... > To: 73607.1231@compuserve.com > From: steve@thelake.UUCP (Steve Yelvington) > Reply-To: pwcs.StPaul.GOV!stag!thelake!steve > ... > >>> RCPT To:<73607.1231@uccba.uc.edu> > <<< 550 <73607.1231@uccba.uc.edu>... User unknown: Not a typewriter > 550 <uccba!73607.1231@hal.cwru.edu>... User unknown > >This part isn't my fault. That specific problem is apparently caused >by a mailer at (I'm guessing here, partially) uccba or CWRU, where it >somehow magically strips one item out of a !-path. I don't think it's my fault, either. My sendmail.cf correctly handles the address hal!uccba!compuserve.com!73607.1231@cwjcc.cwru.edu; it forwards it to hal over the campus net we have here. I think the `compuserve.com' part was gone before it got to cwjcc. Here are the relevant lines from my syslog file: Dec 4 11:47:00 localhost: 21613 sendmail: AA21613: message-id=<1104890237261783 @thelake.UUCP> Dec 4 11:47:05 localhost: 21613 sendmail: AA21613: from=<wuarchive!swbatl!pwcs! stag!thelake!steve@mailrus.cc.umich.edu>, size=2371, class=0, received from saqq ara.cis.ohio-state.edu (128.146.8.98) Dec 4 11:47:14 localhost: 21622 sendmail: AA21613: to=<hal!uccba!73607.1231@cwj cc.cwru.edu>, delay=00:00:17, stat=Sent Chet Ramey Sometime Personification of the Mailer Daemon Case Western Reserve University -- Chet Ramey Network Services Group "Where's my froggie?" Case Western Reserve University chet@ins.CWRU.Edu
eric@ists.ists.ca (Eric M. Carroll) (12/15/89)
>Well, I've had all sorts of problems getting to sites at WU, and have gotten >the most amazing bounces from wuarchive and nearby sites. I suspect that they, >or someone topologically close to them, is a liberal header rewriter. > >Also, texbell.lonestar.org tends to create fictional From: lines. This seems >to be due to a piece of excessive RFC-ishness in smail 3.0 alpha. If you ever >get weird mail with my signature from texbell!Postmaster, that's what happened. Yes, no question - either wuarchive, texbell or someone hiding right around there has been causing me significant grief recently. I have to transit these sites to get to several elm and uucp development people and I consistently get seriously smashed mail from right around here. I suspected mailrus for a while, but convinced myself that its not them. Can anyone help localized this? I cannot bring it to the attention of postmasters I cannot localize. I can likely dig up some paths to help the quest. ---- Eric Carroll Postmaster Institute for Space and Terrestrial Science
eric@egsner.cirr.com (Eric Schnoebelen) (12/16/89)
In article <3333@ists.ists.ca> eric@ists.ists.ca (Eric M. Carroll) writes:
-> Well, I've had all sorts of problems getting to sites at WU, and have
-> gotten the most amazing bounces from wuarchive and nearby sites. I
-> suspect that they, or someone topologically close to them, is a liberal
-> header rewriter.
->
-> Also, texbell.lonestar.org tends to create fictional From: lines. This
-> seems to be due to a piece of excessive RFC-ishness in smail 3.0 alpha.
-> If you ever get weird mail with my signature from texbell!Postmaster,
-> that's what happened.
-
- Yes, no question - either wuarchive, texbell or someone hiding right
- around there has been causing me significant grief recently. I have to
- transit these sites to get to several elm and uucp development people
- and I consistently get seriously smashed mail from right around here.
I've always been suspicious of wuarchive myself. It seems that
I receive a lot of mail that has had the address mangled at wuarchive,
or one of the other wu* machines.
Of course, I may be slightly biased, since texbell is my main
connection to the world, along with attctc.
But, the only time I see mangled things are when they pass by
wuarchive, never had any problems with texbell.
--
Eric Schnoebelen eric@egsner.cirr.com schnoebe@convex.com
"/bin/sh: Bourne in the USA"mauricio@mrecvax.UUCP (Mauricio Fernandez) (01/03/90)
Concerning various messages about UUPC we'd like to add some comments.
We are a group of teachers in the Facultad de Ciencias Exactas y Naturales
of the Universidad de Buenos Aires, Argentina. We are developing a National
Academic Network (RAN = Red Academica Nacional) and we are using UUPC
for most of it. The topolgy is sort of hierarchical with the central
nodes running UUCP under UNIX/XENIX, and most of the leaves running
UUPC under DOS.
We choose this configuration because most of the nodes can't afford any
investment and they usually have PC's, thus it seemed a good idea to
use UUPC.
Because of the wide spread of the network (there are about 80 nodes
running UUPC by now) and because of the little reliability of the
country's telephone network, we were forced to make some patches to
the software.
Concerning the problems that begun these discussions, we also
had to manage them because of the line noise. We had to rise the
time-out and the maximum number of errors and make both of these
external arguments due to diferent qualtity of lines in
different locations in the country.
We also had to control the breaking of the connections which were
not handled properly.
We have also added a time-out that aborts if there is no
reasonable activity in the line during a certain period.
We changed the state machine so that it tries the different
lines in the systems file only if the precedent tries weren't
succesful.
We also added a better error control so that there is
information about the classes of errors (permanent, transitory,
etc.).
We also corrected a bug that kept the lines busy and uucico's
running in the remote host after a succesful communication ended.
If there is someone interested in these changes, you can write
to us and we'll make them available.
We are also interested in new versions of UUPC and patches.
Nicolas Baumgarten
nico@dcfcen.edu.ar
P.S: We are working with version "UUPC/post-1.0-interim"
and "UUPC/uuio version 1.06"
--
Mauricio Fernandez mauricio@mrecvax.mrec.ar