Re: MTS transparency and anonymity

>>>> if anonymous@[] doesn't quite work, there are similar alternatives
>>>> worth considering.  among them are: anonymous@[0.0.0.0],
>>>
>>> No, see RFC 3330; that's a local net.
>>
>> No, see RFC 3330; it's only intended for use as a _source_ address.
>> Trying to connect to the address fails on every platform I know of.
>
> Well, we're talking about a mailbox in the From field, which has
> semantics of a source if anything.

nice try.  but in practice if you try to connect to 0.0.0.0 you'll get 
an error, which is what we want to happen.

>> note that there are a lot fewer TCP/IP stacks in wide use than there
>> are mail-handling programs.  it's much easier to be confident about 
>> the
>> behavior of an IP stack.
>
> Maybe. I recall early implementations where 0.0.0.0 is a
> broadcast address; not all of those implementations have vanished.

I've never seen one.  I've seen lots of implementations where the lower 
bits of a subnet were the broadcast address, but that's a different 
issue.

> But that's really a digression from the issue, because no IPv4
> address has semantics of either "anonymous" or "not on the
> Internet"

nor, for that matter, does any domain.  but it's easier to find an IPv4 
address that has desirable properties than it is to find a domain that 
has them.

> I mentioned RFC 3330 because I looked through it in search of
> just such an invalid (IP) address, and could find none guaranteed
> to remain invalid.  And I looked rather closely at 0.0.0.0 and
> 127.0.0.1.

either 0.0.0.0 or 127.0.0.2 seems to work well as far as I can tell.

>> also, if it happens that a dns query for example.com yields ip address
>> X, it should not be assumed that [email protected] is equivalent to
>> user@[X].
>
> That's not the problem, nor even related to the problem.  The problem
> is that there may be an SMTP (or other mail protocol) server listening
> on the loopback address, and any local-part might be a valid one on
> some such system.

yes, it might happen.  but you can pick a local-part such that it's 
extremely unlikely to happen - less likely to happen than numerous 
other kinds of failures.  even so, 127.0.0.1 would not be my first 
choice.

>>>> anonymous@[127.255.255.255],
>>>
>>> No, also covered by RFC 3330.
>>
>> and if the host correctly implements RFC 3330 ("no addresses within
>> this block should ever appear on any network anywhere")
>
> Yes, the loopback connection is supposed to be internal to the IP
> implementation, and not be translated to any physical network.  That
> still doesn't have semantics of "anonymous" or of "nonexistent"; it
> has semantics of "here".

in practice, it has the semantics of "nowhere", or "you can't get there 
from here, no matter where 'here' is."

>> then this will
>> work just fine, as the host IP stack will return an error when the MTA
>> tries to connect to that address.
>
> You again seem to be focusing on non-replyability, which isn't the
> topic of draft-lilly-from-optional.

it's a backward compatibility issue.  MUAs and MTAs that know about the 
convention are not the problem, since it's easy for them to recognize 
such addresses and treat them accordingly. the problem is making this 
work with MUAs and MTAs that don't know about the convention.

>>>> anonymous@[::0],
>>>> and anonymous@[::1].
>>>
>>> Not valid RFC 2821 syntax.
>>
>> sounds like a bug in RFC 2821.
>
> You're certainly free to make a case for that. The legal 2821 versions
> of IPv6 domain literals would be something like [ipv6:::0]. Yes, it's
> ugly.

hey, I'd be fine with anonymous@[ipv6:::0]

or perhaps even anonymous@[no-such-network:]

>> but if the MTA strictly implements RFC
>> 2821 and rejects the message at RCPT time, that's perfectly okay.
>
> OK for what? For preventing a response (assuming that the message
> gets to a recipient)?  Again, that's not the subject of the draft.

no, but it's the most important technical constraint on the convention 
for an anonymous address.  see above.

>> it  doesn't really matter whether the MTA rejects the address because 
>> the
>> local-part doesn't exist or because the domain has an invalid syntax,
>> as long as it fails.
>
> Are you discussing transport, or the message format?

I'm discussing what it takes to make something like this work in 
practice.  anything that isn't reasonably compatible with existing 
MTAs/MSAs is a non-starter.

> So far as I can see, there is no perfectly clean solution to the
> issues covered in the draft.  However, simply making the From
> field optional -- while that may present some issues -- seems to
> have the least negative impact of the options considered (including
> syntax changes and extension, which present rather more serious
> backwards compatibility issues than making the field optional).

I disagree.  Too many things extract data from the From field.

>>> 2. peeking at the local-part is a layering violation unless
>>>    the domain is yours.
>>
>> for MTAs and UAs, yes.  not for humans.
>
> If there's something there indicating either a domain or a local-part
> within a domain, it fails to provide the desired semantics, viz.
> nothing (i.e. no mailbox).  That itself is not a showstopper, but in
> conjunction with the requirements for gateways, it presents some
> obstacles.

so use the loopback address domain literal.  then it's yours, and you 
can define anonymous addresses however you want :)
(not a serious proposal - but IMHO you're making way too big a deal of 
semantic issues based on strained reading of the specifications and 
giving far too little concern to interoperability with the installed 
base)