At 20:56 -0400 on 07/07/2013, Valdis(_dot_)Kletnieks(_at_)vt(_dot_)edu wrote
about Re:
[ietf-smtp] Multicast MTAs, was Dotless domains and ema:
>2) The ever-dreaded "local alias" problem. Until you've gone thorugh *every*
>corporate and organization network and fixed every single user's address
>book so it doesn't say 'fred@locus' but upgrade it to
>'fred(_at_)locus(_dot_)example(_dot_)com',
>and then fix their MUA to prevent the user from savin a local alias again,
>you won't be able to really reliably use '@locus' as a dotless destination.
I see two separate but related issues here.
Will the MUA append domain to any address which is Dotless (ie:
User@Host) and/or one that is User Only (ie:@-Less)? So long as it
does there is no need to force FQDN addresses since the FQDN address
will be created by the MUA before it hands the message off to the MSA
Server.
Very unlikely. Most MUAs just blort out whatever the user entered and/or
whatever they scarfed off a header line with little if any syntax checking. In
fact I recently ran into an MUA that was sending things like:
RCPT TO:<list: ;>
And getting upset when it didn't work. (And then retrying over and over,
presumably on the theory that if you ask the question often enough maybe you'll
get a different answer.)
The second issue is that we are talking about the address supplied to
the MUA needing to be compliant with the RFC821/2821/5821 rules when
this address is not necessarily what will be submitted to the MSA due
to the domain appending code referenced above. IOW: If I create a
message addressed to fred@locus is the address that is supplied to
the MSA (and in the TO Header) fred@locus or
fred(_at_)locus(_dot_)example(_dot_)com?
Actually we're talking about real world behavior. It would be nice
if there was a perceived need to be compliant, but I for one am not seeing it.
Ned
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp