Hi John,
I came across something today that may be of item of interest or may
need some clarification. I wasn't sure if this comment should or not be
part of Issue 27 since it is labeled as close in your issues list).
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.
So what prompted me to post a comment about a potential new issue?
First, the Received: ABNF includes the From-domain entity:
From-domain = "FROM" FWS Extended-Domain
Extended-Domain = Domain /
( Domain FWS "(" TCP-info ")" ) /
( Address-literal FWS "(" TCP-info ")" )
For Address-literal, we have:
address-literal = "[" ( IPv4-address-literal /
IPv6-address-literal /
General-address-literal ) "]"
; See Section 4.1.3
(Side Nit: Note the blank line)
Of course, putting aside the issues of mixed non-compliant practices in
the field, per ABNF specification, the address-literal MUST be enclosed
within brackets.
Well, we have a throw away Google gmail.com account that we use for
testing various things. Working from my home office machine using the
MUA Thunderbird 2.0, I was exploring sending mail using the gmail.com
account. gmail.com allows MUA based offline posting and it requires the
SUBMIT protocol (port 587) with TLS to be prepared in the MUA for this
account.
I sent a test message which I quickly received at gmail.com. I looked
at the header lines and noticed something odd in the gmail.com server
adding of its Received: trace line:
Received: from ?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)
Note the from address-literal with the question marks - ?192.169.1.101?
The MUA client actually sent:
EHLO [192.169.1.101]
So one of the largest ISPs in the world, is altering the Received line
by using replacing the brackets for question marks.
Rhetorically, why would it do this? Why not just use the bracketed
address literal provided?
Again, Rhetorically, I ask, does the google server even support the
reading of bracketed IP address-literal for EHLO/HELO or any other
address-literal provided during the transaction?
If there are any google gmail.com lurking this list, they might want to
chime in about the above.
To help explore these question, I went ahead and performed more test to
see how it handled the EHLO/HELO. I sent five (5) new messages with
each using different EHLO with the following Received line results:
1) SMTP compliant bracketed address-address, IP matching
EHLO [68.215.50.125]
--> Received: from ?68.215.50.125?
2) No bracketed address-address, IP matching
EHLO 68.215.50.125
--> Received: from 68.215.50.125
3) Simulate what Outlook would do (sent computer name)
EHLO hdev1
--> Received: from hdev1
4) Use the real/correct ptr domain
EHLO adsl-215-50-125.mia.bellsouth.net
--> Received: from adsl-215-50-125.mia.bellsouth.net
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
Based on all this I can take a SWAG that
a) Google is not supporting bracketing address-literals,
b) Google replaces unexpected characters with '?' for
the Received line address-literal field.
c) Even though the transaction requires the strong SUBMIT 587
protocol, it it relaxed on not enforcing correct
address-literal syntax IP matching nor rDNS check authentication.
The latter (c) is a separate issue, but it might reflect the importance
or unimportance of the bracketed address-literals.
Why or how could any of this constitute 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?
--
HLS