wb8foz@mthvax.cs.miami.edu (David Lesher) (12/24/90)
I've got a couple bogus address questions: I've been seeing posts from people with valid FQDN From: headers, but then an added Reply-To: foobar.UUCP header too! Now I know the bogus .UUCP cruft in the From: headers typically comes outdated versions of 'rn,' but what is adding the Reply-To: errors? I see too many to think they are being done by hand. Secondly, one site on the net seems to be deliberately BREAKING outgoing addressing by making all postings and mail come from: nobody@XXXXX.com and doing the same with the Reply-To: line, too. This seems to be some internal dispute in the company. My question is: what do the RFC's say about generating unusable addresses? -- A host is a host from coast to coast.....wb8foz@mthvax.cs.miami.edu & no one will talk to a host that's close............(305) 255-RTFM Unless the host (that isn't close)......................pob 570-335 is busy, hung or dead....................................33257-0335
tronix@polari.UUCP (David Daniel) (12/25/90)
[]I've got a couple bogus address questions: [] []I've been seeing posts from people with valid FQDN From: headers, but []then an added Reply-To: foobar.UUCP header too! [] []Now I know the bogus .UUCP cruft in the From: headers typically comes []outdated versions of 'rn,' but what is adding the Reply-To: errors? I []see too many to think they are being done by hand. I use rn at my site and will relate my experience: I've had instances where our DNS (sumax) will mangle my From: line to read something like @polari@sumax or @sumax@polari.UUCP. In any case it's unusable. By using the .RNINIT option one may customize a header to read any way one wants it to. I've added my return address to the Reply-To: line so that I can get mail replies even if sumax mangles my From: line. It also seems that some people have fairly complicated networks where they'll post from their account which passes to another machine like news@xxx.xx or like blarson that passes thru two machines I think. I've also seen people change their headers completely using .RNINIT or its equivalent when posting to the more "sensitive" newsgroups so that only the message ID is left (probably) unchanged. [] []Secondly, one site on the net seems to be deliberately BREAKING []outgoing addressing by making all postings and mail come from: [] nobody@XXXXX.com Maybe it's their equivalent of news@xxxx.com? []and doing the same with the Reply-To: line, too. Oh, then it's somebody screwing around most likely. Damn college kids.... :] [] []This seems to be some internal dispute in the company. My question is: []what do the RFC's say about generating unusable addresses? I haven't read any myself but I'd guess that it was never even considered: Why would anyone want to? See above. [] [] []-- []A host is a host from coast to coast.....wb8foz@mthvax.cs.miami.edu []& no one will talk to a host that's close............(305) 255-RTFM []Unless the host (that isn't close)......................pob 570-335 []is busy, hung or dead....................................33257-0335 That one of my favorite .sigs! -- David Daniel (The man with no disclaimer) tronix@polari.UUCP "Beware the Truth. If you find a Truth it can demand that you make painful changes." - Frank Herbert
nelson@sun.soe.clarkson.edu (Russ Nelson) (12/26/90)
In article <2983@polari.UUCP> tronix@polari.UUCP (David Daniel) writes:
[]I've got a couple bogus address questions:
[]
[]I've been seeing posts from people with valid FQDN From: headers, but
[]then an added Reply-To: foobar.UUCP header too!
[]
[]Now I know the bogus .UUCP cruft in the From: headers typically comes
[]outdated versions of 'rn,' but what is adding the Reply-To: errors? I
[]see too many to think they are being done by hand.
Rn's INIT file has model headers. The Reply-To: field has a %s.UUCP in it,
*even* if your site has a FQDN, and uses it in the From: field.
[]Secondly, one site on the net seems to be deliberately BREAKING
[]outgoing addressing by making all postings and mail come from:
[] nobody@XXXXX.com
Oh, you mean kodak.com? [call a spade a spade.] I've been yelling at
their postmaster for months, or more correctly, telling Kodak users to
yell at their sysadmin. No change yet.
-russ
--
--russ (nelson@clutx [.bitnet | .clarkson.edu]) FAX 315-268-7600
It's better to get mugged than to live a life of fear -- Freeman Dyson
I joined the League for Programming Freedom, and I hope you'll join too.wb8foz@mthvax.cs.miami.edu (David Lesher) (12/26/90)
(Russ Nelson & David Daniel) and others followed up on my questions, but I don't seem to have made my point clear enough. but what is adding the Reply-To: errors? I see too many to think they are being done by hand. I know about the RNINIT variable. (nn lets you do the same. ) I also know that old versions of rn called everyone a .UUCP site, (in the From: line) EVEN IF THEY ARE DIRECTLY CONNECTED. My question is: Who/what is adding the bogus .UUCP Reply-To: headers? I'm hard pressed to believe that all those users out there are doing so one at a time. I see too many. Is there some piece of net software that is perpetuating the rn error, extended to the Reply-To: line, also? re: nobody@xxxxx.com >Oh, you mean kodak.com? [call a spade a spade.] I've been yelling at >their postmaster for months, or more correctly, telling Kodak users to >yell at their sysadmin. No change yet. My understanding, (secondhand, of course) is that the postmaster is doing this deliberately. I doubt yelling at such will do anything, hence my RFC question. On the other hand, I am a {very minor} stockholder. Maybe I should write to the CEO about this abuse of my earnings/share. -- A host is a host from coast to coast.....wb8foz@mthvax.cs.miami.edu & no one will talk to a host that's close............(305) 255-RTFM Unless the host (that isn't close)......................pob 570-335 is busy, hung or dead....................................33257-0335
mcb@reason.ig.com (Michael C. Berch) (12/27/90)
In the referenced article, tronix@polari.UUCP (David Daniel) writes: > I use rn at my site and will relate my experience: > > I've had instances where our DNS (sumax) will mangle my From: line to > read something like @polari@sumax or @sumax@polari.UUCP. In any case > it's unusable. By using the .RNINIT option one may customize a header > to read any way one wants it to. I've added my return address to the > Reply-To: line so that I can get mail replies even if sumax mangles my > From: line. The best way to assure that your From: line doesn't get mangled is to register and use a FQDN. If you registered as "polari.seattle.wa.us" or "polari.com" or whatever, mailers would be much less likely to want to gratuitously rewrite your headers (it *does* happen, as the current thread in comp.mail.misc shows). So long as you remain in the .UUCP pseudo-domain, mailers seem to take this as license to rewrite your sender fields. -- Michael C. Berch mcb@presto.ig.com / mcb@postmodern.com / uunet!presto.ig.com!mcb
bob@MorningStar.Com (Bob Sutterfield) (12/27/90)
In article <1990Dec24.025350.26945@mthvax.cs.miami.edu> wb8foz@mthvax.cs.miami.edu (David Lesher) writes:
what do the RFC's say about generating unusable addresses?
See RFC822:
4.4.1. FROM / RESENT-FROM
This field contains the identity of the person(s) who wished
this message to be sent.
Section 5 of RFC1123 discusses well-behaved mail systems. The
attributes that are made explicit for mail gateways and mailing lists
and assumed implicitly for Internet mail include headers that are
"effective and useful for sending replies."tronix@polari.UUCP (David Daniel) (12/27/90)
[]The best way to assure that your From: line doesn't get mangled is to []register and use a FQDN. If you registered as "polari.seattle.wa.us" []or "polari.com" or whatever, mailers would be much less likely to want []to gratuitously rewrite your headers (it *does* happen, as the current []thread in comp.mail.misc shows). So long as you remain in the .UUCP []pseudo-domain, mailers seem to take this as license to rewrite your []sender fields. I agree. I've been following the ongoing 'which headers may sendmail rewrite' topic with great interest and plan on talking to the admin here about his plans (or lack of) to register polari as a FQDN. I have a question about that:The info I have from uunet says they'll do it for $35.00. But does all our mail have to route thru them? If not, then I assume that they would export the new domain name to all smart hosts. Does the NIC play a part in the registration process? If so how? Presently is appears that sumax rewrites my header to appear as either polari!tronix@sumax.seattle.edu or as tronix%polari@sumax.seattle.edu. In the latter version the '%' seems to read as 'at' and the '@' reads as 'via'. Correct? []Michael C. Berch []mcb@presto.ig.com / mcb@postmodern.com / uunet!presto.ig.com!mcb -- David Daniel (The man with no disclaimer) tronix@polari.UUCP "Beware the Truth. If you find a Truth it can demand that you make painful changes." - Frank Herbert
fair@Apple.COM (Erik E. Fair) (12/31/90)
In the referenced article, oc@vmp.com (Orlan Cannon) writes: > >To register through UUNET, you must find a UUNET subscriber who is >willing to forward all your mail for you. This is false. You must find an Internet site that is willing to forward for you, but that site doesn't have to have any relationship at all to UUNET. We forward for about two dozen domains in the south S.F. Bay Area, most of whom registered their domain through UUNET. We are not related to UUNET in any way, save that both Apple and UUNET are on the Internet. >All mail generated on the >Internet or rabidly rerouted on the Internet will be routed to >UUNET. This is false. The only E-mail we route through UUNET is E-mail that is destined for their subscribers, as indicated in the UUCP maps. All other routers who use the maps (and I dare say that all of them do; to do otherwise would be stupid) behave the same way (that is, they route appropriate traffic through UUNET). > >>Does the NIC play a part in the registration process? If so how? > >The NIC is the final word in registrations. It keeps a master copy of >all registrations, makes sure there are no duplicates domain names, >etc. It generates a new and definitive HOSTS.TXT every two weeks. HOSTS.TXT and the DNS are pretty much divorced at this point. Perhaps you were thinking of DOMAINS.TXT? Erik E. Fair apple!fair fair@apple.com