[comp.mail.sendmail] FUZZY matching in 5.65a/IDA-1.42

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