casey@admin.cognet.ucla.edu (Casey Leedom) (09/28/88)
In article <710@mailrus.cc.umich.edu> emv@mailrus.cc.umich.edu (Edward Vielmetti) writes: > In <691@mailrus.cc.umich.edu> I wrote about turning > <user at host> => <user@host> > messed up mail to > <user@star.at.man.ac.uk>. > > If you have a sendmail ruleset that reads > R$+ at $+ $1@$2 > > it would be a good idea to remove it. Who generates "at"s > any more, anyway? Hhmmm, why so it does. Amazing. Well, if you change the rule to: R$1+\ at\ $+ $1@$2 (at least on sendmail 4.12), it starts working correctly. It appears that while the sendmail document does say: Section 5.1.1 ... Rlhs rhs comments The fileds must be separated by at least one tab character; there may be embedded spaces in the fields. ... it doesn't specify what embedded spaces *mean* ... In any case, the point is somewhat moot since Edward's comment is pretty valid: I don't think anyone is generating ``user at host'' addresses any more, and if they are, ripping the above rule out of sendmail.cf will force them to get rid of the brain damage. Casey
brian@ucsd.EDU (Brian Kantor) (09/29/88)
Leaving aside for the moment the entire question of whether sendmail should be doing anything to lines in the header, it is regrettably true that we see USER AT HOSTNAME in the headers we get from the BITNET quite often --- at least, often enough to matter. Sigh. Brian Kantor UCSD Postmaster UCSD Office of Academic Computing UCSD B-028, La Jolla, CA 92093 USA brian@ucsd.edu BRIAN@UCSD ucsd!brian
page@swan.ulowell.edu (Bob Page) (09/29/88)
> R$+ at $+ $1@$2
RFC 822 says this is not legal anyway, in case somebody gets upset with
you for rejecting it. (so much for "be liberal in what you accept ...")
C.5.5. AT-SIGN
The string " at " no longer is used as an address delimiter.
Only at-sign ("@") serves the function.
..Bob
--
Bob Page, U of Lowell CS Dept. page@swan.ulowell.edu ulowell!pagewisner@killer.DALLAS.TX.US (Bill Wisner) (09/29/88)
>we see USER AT HOSTNAME in the headers we get from the >BITNET quite often --- at least, often enough to matter. Shouldn't gateways take care of this?
simon@iclitc.uucp (Simon Kenyon) (09/30/88)
foo at bar is generated by certain bitnet (earn) sites turning it off in sendmail would therefore be a very BAD idea EUnet is trying very hard to work with EARN there is no point in screwing that up over nothing of inportance a cure to the problem is described in your mail message -- simon
casey@admin.cognet.ucla.edu (Casey Leedom) (10/04/88)
> From: vjs@rhyolite.sgi.com (Vernon Schryver) > > > Hhmmm, why so it does. Amazing. Well, if you change the rule to: > > > > R$+\ at\ $+ $1@$2 > > > > (at least on sendmail 4.12), it starts working correctly. > > I tried this, I think, but can't make it work. With the backslashes, the > rule does not seem to match 'joe at foobar' at all. (I'm assuming > everything we're talking about is a blank, not a tab.) What am I missing? > > SGI's sendmail is currently 5.52 with pathalias hacks similar to IDA, but > done earlier or at least independently. Uh sorry, I should have looked before I leapt. I just tested the fact that it would no longer match on ``user@foo.at.bar''. I forgot to test ``user at foo''. Very sloppy of me. Unfortunately, now that I've been forced to look at it harder than is required for a flip answer, I can see what the problem is. Rules are read by the same code which reads addresses. Hence the interpretation of spaces (per RFC822). [RFC822, section 3.4.2, WHITE SPACE: Note: In structured field bodies, multiple linear space ASCII characters (namely HTABs and SPACEs) are treated as single spaces and may freely surround any symbol. ...] Even if you do get the spaces into the rule properly by quoting them (again as per RFC822 now that we know how sendmail parses rule set LHSs) via: R$+" "at" "$+ $1@$2 It still won't match ``user at host'' because the address string's spaces aren't quoted! That is, the address would have to come in as: To: user" "at" "host And fundamentally we're screwed at this point because by the time our rewriting rules get a crack at an address, this level of parsing has already gone down on the input address so that given the line: To: user at host all we ever see are the tokens "user", "at", and "host". We don't get to see the spaces. What you'd like to do is somehow define a class, say o, that contained all the delimiter tokens, then write the rule as: R$+$~oat$~o$+ $1@$2 but, unfortunately, sendmail's class matching code is just a little weak, so this doesn't work. (Not even Sun's sendmail handle's this bit of class matching and Sun's sendmail through Bill Nowicki's work has a lot of fixes to the class matching code.) The ``user at host'' translation could probably be done through a complicated series of tokenizations and retokenization, but I wouldn't want to try to come up with it, or maintain it, or even look at it. The solution is probably just to remove the rule and let gateways that absolutely have to do it. Better yet, have everyone remove it and force the offending sites generating the addresses to ditch the form. Casey