John C Klensin wrote:
Quite possibly, in summary, it may be deemed a new issue,
possible two:
- Clarifying Bracketed address-literals MUST requirement, and
- discouraging alterations of the address-literal for
the trace line.
The two may be related and possible be folded into 1 issue.
Or it may be no issue at all... I'll leave that up to Tony and
general discussion.
Right, that was implied above.
The MUA client actually sent:
EHLO [192.169.1.101]
First of all, note that most MTAs who use a
... from domain-or-literal ( literal ) ...
format are announcing that the actual IP address of the
sender-SMTP was different from the IP address specified (or
associated with the domain name given). They are prohibited (in
relays) and discouraged (in submission servers) from rejecting
mail on that basis, but warnings have long been considered
appropriate.
You, and others, have questioned that rule, both wrt NAT-based
addresses and about whether it has become a proper basis for
rejection.
Right, it is a separate issue (IP literal matching) but it was the
genesis of finding this behavior with Google.
As you may recall, Thunderbird now offers a way to allow users to define
the EHLO/HELO argument to address the above private ip literal issue
with clients residing on private NAT networks. That is how I was able
to perform the test to define the different EHLO/HELO arguments.
But the configuration is on a per server basis. When I added the Google
gmail.com account to my Thunderbird 2.0 MUA, it used the default
behavior, thus the private IP literal for the EHLO command above.
Now, my personal preference would have been to document this a
little differently, partially because I don't like adding syntax
violations to the complex of problems that are there already.
But it is a matter of taste and a territory into which I don't
think 2821bis needs to go or should go. I think I would prefer
that a server deal with situations like this one by inserting
something more like
Received: (from bogus-NAT-address 192.168.1.101
[68.215.50.125])
by mx.google.com with ESMTP id
h17sm2595511wxd.2007.04.27.19.07.38;
Fri, 27 Apr 2007 19:07:38 -0700 (PDT)
or maybe, taking liberties with a different rule,
Received: from [68.215.50.125]
(EHLO bogus NAT address 192.168.1.101)
by mx.google.com with ESMTP id
h17sm2595511wxd.2007.04.27.19.07.38;
Fri, 27 Apr 2007 19:07:38 -0700 (PDT)
and this is partly why I brought it. The Received: line has been an
issue that many have been trying to stabilize to increase the automated
aspects of reading it. It seems to me that many packages simply did not
establish any reliable faith on using it for any automated concept.
Looking at this example only for the moment and ignoring the
other things you found out about Google's behavior, a
receiver-SMTP that does this could be doing something creative
with the syntax to note the fact that the smtp-Sender has
violated 2821 by issuing an invalid EHLO command (because it
uses a private address on the public Internet, not because of
syntax) and it has decided to accept and transport the mail
anyway. I don't particularly like the syntax of their
announcement that they have done so, but the standards violation
occurs earlier and I have to approve of their attempt to
document the violation --and the situation as it appears from
their end-- carefully.
I see your point, but it seems to me that it might be better to have
some "standard" way of documented that failure or not documenting it and
just record "as is" what was provided and allow the post processing MFA
(Mail filtering Agents) to react to it, if applicable.
Case in point: SIEVE, SPAM ASSASIN. I though they expect to see
questions marks. So if it was an upfront error, should the receiver
record this error or just record the information for others systems to
read as it expect it to read it? Remember, in this case, the error was
not the syntax itself, but that it didn't match the connecting IP
address. But Google didn't record it as a IP mis-match error, but
rather that it didn't understand the brackets.
1) SMTP compliant bracketed address-address, IP matching
EHLO [68.215.50.125]
--> Received: from ?68.215.50.125?
Bug, IMO.
Right, so does it make sense to add any instead that it should either
record it "as is" or do we come up with other method to record the error?
Again, keep in mind that there are MFAs (Mail Filtering Agents) that may
not expect the questions marks for address-literals as part of
from-domain field.
2) No bracketed address-address, IP matching
EHLO 68.215.50.125
--> Received: from 68.215.50.125
Worse bug, IMO. But, of course, this is also a client violation.
Right.
3) Simulate what Outlook would do (sent computer name)
EHLO hdev1
--> Received: from hdev1
Different bug, but also a client violation.
For which unfortunatly, servers has to shallow if they don't wish to
alienate one of the largest pool of end users.
4) Use the real/correct ptr domain
EHLO adsl-215-50-125.mia.bellsouth.net
--> Received: from adsl-215-50-125.mia.bellsouth.net
behaving as expected.
5) Use the incorrect ptr domain (125 changed to 126)
EHLO adsl-215-50-126.mia.bellsouth.net
--> Received: from adsl-215-50-125.mia.bellsouth.net
Sorry, on the received: output, it should of been:
Received: from adsl-215-50-126.mia.bellsouth.net
> With no IP address in brackets? Clearly permitted by 2821 (and
> 821), but probably not in particularly good taste today. Still
> not a 2821bis issue, IMO.
The client behavior SHOULD be:
- Obtain the IP address on the machine,
- Obtain the domain for this IP (PTR lookup),
- If none, use bracketed IP literal.
For test #4, I simulated the idea that the NAT machine was sending the
transaction by using the proper domain for the public IP of this machine.
For test #5, to check to see if Google was performing an domain/IP
match, like many ISP servers do, I simulated an altered domain name
(changing 125 to 126) to see if Google was going to do domain/ip check.
It did not.
Or might reflect the more general possibility that someone at
gmail is asleep at the switch.
I wonder if an gmail.com engineer is lurking here. I'll see if I can
find an appropriate contact address to send the note.
Why or how could any of this constitute [an issue] for 2821bis?
Well, in our quest for clarifying and codifying existing and
possible dominant behavior, for new implementors what I can
see occurring is they begin may use systems like GOOGLE
gmail.com as a design baseline for practical and good
2821/2822 protocol behavior. They may follow their lead,
including not expecting brackets and also converting them to
questions marks for the trace line.
Comments anyone?
This is the same problem that we had when some people were
assuming that whatever sendmail was doing was the spec, without
looking at the spec, 20 years ago. It was a problem then, it is
a problem now... only the previous bad actor has cleaned up its
act and the new bad actor has. It is not a problem with the
standard, IMO, unless someone can go find the relevant gmail
people and get them to tell us that their trace field
implementation ended up this way because they got confused by
the spec. Otherwise, this is interesting, and sad, but not a
problem.
I agree. Its the same issue as with the reply codes. The difference
being is that the BCP is not to reject or more appropriate fail the
transaction on this basis. Hence its hasn't been a big issue.
But thats changing. In the name of spam/security, that is clearly changing.
I just figured maybe there would be a need to embedded, "fit" a few
highlighted technical MUST about the protocol expects.
I'm just winging it now, but maybe something like:
Please note, SMTP-clients MUST enclose address-literals with
brackets.
and,
SMTP-Receivers MUST|SHOULD use the address-literals unmodified when
recoding the From-Domain field in the Received: header.
Something simple, something to clarify what is already "implied" in the
specs.
Thanks
--
HLS