mikem+@andrew.cmu.edu (Michael Meyer) (06/22/91)
I'm using sendmail 5.65a/IDA-1.42 with fuzzy name matching turned on. I have noticed that if there is a user, say "Fred Blogs" with user name fb23 then mail to fred.blogs will get spooled to /usr/spool/mail/fb23 even if there is an entry in /etc/aliases. I would like to retain the fuzzy name matching but would prefer to see the mail sent to the "right" place (where /etc/aliases says it should go). Is there any easy fix? Is there a later version of sendmail/ida that I should be using? Thanks, Mike Meyer
rickert@mp.cs.niu.edu (Neil Rickert) (06/22/91)
In article <0cMZDsO00j41MBwG8F@andrew.cmu.edu> mikem+@andrew.cmu.edu (Michael Meyer) writes: >I'm using sendmail 5.65a/IDA-1.42 with fuzzy name matching turned on. >I have noticed that if there is a user, say "Fred Blogs" with user name >fb23 then mail to fred.blogs will get spooled to /usr/spool/mail/fb23 >even if there is an entry in /etc/aliases. I would like to retain the >Thanks, >Mike Meyer If you had an alias for fred.blogs that would be used. The fuzzy matching occurs after the time that alias looking is done. This is not really an IDA problem. It is an expectation problem. You were always able to bypass alias matching for the 'fb23' alias if the mail were sent to "fb23" or f"b2"3 or \fb23 (etc) instead of to fb23. For that matter a user could do: /bin/mail -d fb23 < file and bypass sendmail completely. Here we have disabled fuzzy matching. I believe Paul Pomes has done the same at uiuc.edu. It just causes too many problems. It is too easy, for example, for a mistyped address to fuzzy match the wrong person, thereby "publishing" information which was meant to be private. It would be safer for you to have an alias fred.blogs: fb23 so that mail to Fred.Blogs still gets to fb23. In that case the aliasing and forwarding for fb23 will still work. But, if you still want to use the fuzzy matching, here is another approach. Try using Chip Salzenberg's 'deliver' package as a replacement for /bin/mail, and then use the "aliasing" features of deliver. This moves a level of aliasing to a point beyond where the fuzzy matching is complete. -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Science <rickert@cs.niu.edu> Northern Illinois Univ. DeKalb, IL 60115 +1-815-753-6940
he@spurv.runit.sintef.no (Havard Eidnes) (06/26/91)
In article <1991Jun21.204805.15905@mp.cs.niu.edu> rickert@mp.cs.niu.edu (Neil Rickert) writes: > > This is not really an IDA problem. It is an expectation problem. You >were always able to bypass alias matching for the 'fb23' alias if the mail >were sent to "fb23" or f"b2"3 or \fb23 (etc) instead of to fb23. For >that matter a user could do: /bin/mail -d fb23 < file >and bypass sendmail completely. Uh-oh. This reminds me of a problem I have seen just recently. Someone wanted to send to an address which contained a space character in the local-part (don't ask, there are reasonably sensible reasons for wanting to do this). The sending mail agent (or whoever) had decided that it was safest to put the local-part in double quotes, like this: RCPT TO: <"Joe Richard.User"@some.dom.ain> The receiving host has an alias with this space character in it, of the form Joe Richard.User: joeuser However, sendmail decides *not* to even try to look up this alias. I tended to think that this was an oversight or a bug in sendmail, but the above comments seem to indicate that this is intended behaviour. Is there no hope of modifying (IDA) sendmail to handle this the way I thought it should be handled? - Havard
rickert@mp.cs.niu.edu (Neil Rickert) (06/26/91)
In article <1991Jun25.193452.10400@ugle.unit.no> he@spurv.runit.sintef.no (Havard Eidnes) writes: >Uh-oh. This reminds me of a problem I have seen just recently. Someone wanted >to send to an address which contained a space character in the local-part >(don't ask, there are reasonably sensible reasons for wanting to do this). >The sending mail agent (or whoever) had decided that it was safest to put >the local-part in double quotes, like this: It is not just a matter of "safest". The standards require quoting in this case. >RCPT TO: <"Joe Richard.User"@some.dom.ain> > >The receiving host has an alias with this space character in it, of the form > >Joe Richard.User: joeuser > You could have used an alias: "Joe Richard.User": joeuser >However, sendmail decides *not* to even try to look up this alias. I tended to It looks up the alias EXACTLY. Later, after all alias expansion is complete, any "quotes" are removed. Provided there is no \backquote the .forward is then looked up (assuming the user exists). Presumably it would be possible. There are an enormous number of complications you have to think about. The problem arises very rarely, so it is questionable whether the effort is justified. There are workarounds, as my earlier posting mentioned, such as doing a final stage of aliasing in the delivery agent after the unquoting has been done. -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Science <rickert@cs.niu.edu> Northern Illinois Univ. DeKalb, IL 60115 +1-815-753-6940