[comp.soft-sys.andrew] Bug in mswp.c

nsb@THUMPER.BELLCORE.COM (Nathaniel Borenstein) (09/19/90)

There's a bug in ams/libs/ms/mswp.c that kicks in if you're configured
with AMS_UUCPSupported non-zero, i.e. if you're trying to let addresses
like "foo!bar" pass through AMS address validation.  I can supply about
half the fix, and I suspect Craig is a better person to supply the other
half.

In mswp.c, around line 1636, you'll find code that tries to handle the
case where la_Kind has returned latype_Remote but there's no host name
in the address, which is the case when you just give an address like
"foo!bar".  Currently,  that case is handled by the following clause:

    	    } else {
                *ErrCode = MSWP_UNKNOWNNETMAIL;
            }

Unfortunately, this results in having the user interface ask you a
question like, "Are you sure the host <bad parse> really exists?"  I
think this dates back to a time when the idea of la_Kind returning
latype_Remote without a host name just didn't make any sense.  I've
replaced it with the following code, which works much better for me:

    	    } else {
                if (AMS_ValidateDestHosts == 0) {
                    *ErrCode = MSWP_GOODNETMAIL;
                } else if (AMS_UUCPSupported) {
                    /* If local address is "foo!bar!baz", we need to
    validate "foo" here and return either MSWP_GOODNETMAIL or
    MSWP_BADNETMAIL.  However, I'm not 100% sure the right code for
    this, so I'm cheesing out and letting it bounce back if it doesn't
    validate  -- NSB, 9/18/90 */
                    *ErrCode = MSWP_GOODNETMAIL;
                } else {
                    *ErrCode = MSWP_UNKNOWNNETMAIL;
                }
            }

Now, this works fine for me because I happen to have
AMS_ValidateDesthosts turned off -- we do NO host name validation here. 
However, in the case where you're running with hostname validation
turned on and AMS_UUCPSupported also turned on, you'll need to replace
my comment with the appropriate code.  I thought about doing so, but
wasn't sufficiently clear on the finer points of the code (is calling
ValidateMailhostName enough, or do we need to worry about aliases?) that
did hostname validation, which I think Craig can handle better than me. 
Probably it will look something like this, though it's untested and
probably also needs to handle the temp fail case:

... get "foo" into a new string here...
*ErrCode =  (ValidateMailHostName(foostr, Buf, sizeof(Buf)) ==
mailhost_good) ? MSWP_GOODNETMAIL : MSWP_BADNETMAIL

At any rate, some variant of this fix should be installed.  Currently,
my users have to hand-type something like "foo!bar@thumper" instead of
"foo!bar" in order to avoid this stupid bug.

As always, feel free to contact me if you have any further questions.

-- Nathaniel

Craig_Everhart@TRANSARC.COM (09/19/90)

I don't believe that the host name validation code works at all in the
UUCP-connected case, so my inclination would be to turn latype_Remote
into MSWP_GOODNETMAIL if you're trying to run with AMS_UUCPSupported.

Thus, let's replace the section that Nathaniel quoted:

    } else {
	*ErrCode = MSWP_UNKNOWNNETMAIL;
    }

with the almost-as-simple form:

    } else {
	*ErrCode = (AMS_UUCPSupported ? MSWP_GOODNETMAIL : MSWP_UNKNOWNNETMAIL);
    }

Or does anything in the gethostbyname() family work for UUCP-connected hosts?  I don't think it does--instead, the set of UUCP-connected hosts is listed in the delivery system (e.g. sendmail) and in processes it runs, but nowhere where it's quick to validate from an everyday user process.

		Craig

nsb@THUMPER.BELLCORE.COM (Nathaniel Borenstein) (09/19/90)

OK, I agree with Craig about this fix.  (I knew he'd know better!)  All
that has to be done, then, is to replace the line that says

*ErrCode = MSWP_UNKNOWNNETMAIL;

with Craig's replacement:

*ErrCode = AMS_UUCPSupported ? MSWP_GOODNETMAIL : MSWP_UNKNOWNNETMAIL;

A nice, simple, fix to a genuine bug. Thanks, Craig!  -- Nathaniel