[Top] [All Lists]

Re: 2821bis-03: Receive line From-domain Address-literal usage

2007-04-28 19:49:13

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 []

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

You, and others, have questioned that rule, both wrt NAT-based
addresses and about whether it has become a proper basis for

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 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
      by with ESMTP id
      Fri, 27 Apr 2007 19:07:38 -0700 (PDT)

or maybe, taking liberties with a different rule,

Received: from [] (EHLO bogus NAT address
      by with ESMTP id
      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 []

        --> Received: from ?

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


        --> Received: from

Worse bug, IMO.  But, of course, this is also a client violation.


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


        -->  Received: from

behaving as expected.

5) Use the incorrect ptr domain (125 changed to 126)


        -->  Received: from

Sorry, on the received: output, it should of been:

    Received: from    

> 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 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 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

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


  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.