[Top] [All Lists]

Re: Strict RFC x821 Compliant: MAIL FROM:

2005-07-06 07:05:36

----- Original Message -----
From: "Matti Aarnio" <mea(_at_)nic(_dot_)funet(_dot_)fi>

Yes John, we have been at this for way too long, and have seen
everything...  I just wish  SPF specifiers have equally
old hands.

So you haven't seen everything? :-)

You have seen everything, but like me for a long time, we were stuck in a
time warp of not doing anything about it for a long time.

For me and for many, the last straw  was when SORBIG started to forge
addresses and exploiting every loophole in the SMTP level.

SPAM? I could care less, thats an administrative/user policy.

I am more interesting in securing the SMTP TMS (Transaction Management and
Security) process to the highest degree possible
with maximum backward compatibility.

I have a feeling that we need a new part on the specification,
which in itself is informal, but..
Well, or a separate BCP RFC ?

Maybe the ultimate way, especially if the 2821bis document isn't going to
address any of the TMS issues.   If so, I don't mind saying I would be
greatly disappointed because to me, there is some form of stubborness and
even incompetence in not understand the reality of today.   Any SMTP "old
hand" that chose to ignore the MARID, SPF and SENDERID/PRA, well, to me, is
disturbing.  I have full respect for people, but we can't ignore these
issues any more.  Something got to give.

So I personally prefer if there is going to be a new 2821bis document, I
would like it to include the new considerations.

  Following details have been seen to be escaping client
  implementers attention  (this includes both user agents,
  and servers as SMTP client):

My comments are geared towards the significant level as
far as TMS in a vendor that have to operate with other SMTP servers as well.

   - Adding spaces into what specification does not specify
     them, most commonly as:  "MAIL FROM: <...>"

Due to the wide spread. Tolerance is preferrable. This is
the current status in ~100% of all mail servers.

   - Sending MAIL and RCPT without angle brackets

Instant reject in the majorit of servers.

   - Sending utter junk and/or wrong syntax in HELO/EHLO line

Due the existence relaxed provision in HELO, most servers ignore everything
about the client domain name.

We need to address this at the most simplistic and purist level. I cited two
possible ways that I believe should not have any effect on reliable

        - domain literals syntax and IP verifcation
        - Local Domain Spoofing.

   - Not sending HELO/EHLO greeting at all

Inject STATE machine violation.

   - Failing to do reply data collection properly, and just
     presuming that single network read will always yield
     all of the reply.

Each system handles this differently.  But technically this is a state
machine violation, so many systems have a count of the number of sequential
50x errors and do a drop.

The problem with drops is that the sender might call back again.  So you
have to be careful.

A good dicussion item (which if I remember, is already there), but it might
be worth a revisit.

   - Missing the requirement to support multiline replies
     from servers, and that in multiline replies the last
     line value is what determines the reply.

This is a BIG item for stopping BULK senders who try to blast/stream SMTP

What I have seen here is that the sender drops on their own when they don't
see the final non-dash response code.

So I don't think you have any control here because it is the sender that is
broken and will drop.

Nonetheless, a good discussion item about developer and operations who offer
multiple/extended response lines.

   - Missing entirely reply-code principles, e.g. that their
     treatment MUST go by the first digit, deeper semantics
     may be applied, but basic codes are so overloaded, that
     only first digit is usually meaningfull.

I have seen issues here, but I suspect you are trying to use
extended codes to define text presentations or meanings?

If anything, is that that senders might not honor temporary vs permanent
response codes. I believe this is already discussed
and well understood.

This might be a good discussion item about "GreyListing" considerations.

   - Not showing protocol exchange and remote end replies to user,
     when sending fails for whatever reason  (so that user can
     report them to helpdesk - or see right away, why the message
     or one of its recipients didn't go thru.)
     For 99% of things, showing last sent protocol line, and received
     error reply for it will do.  For the remaining 1% a full
     protocol exchange from the connection down to close is needed.

Ok,  however, keep in mind that there is good reasons to not "feed the
hackers/spammers" more information then they need.

But IMO, I don't see this as a SMTP thing.  It is a administrative concept.

   - Single MAIL-transaction can not have more than 100 recipients,
     when more are to be sent, multiple transactions are needed.
     (Most servers allow more, some allow a lot less..)

This is already convered in implementators as options.

However, I think they might be a discussion in how RSET is used to restart a

   - If server advertises EHLO capability to do user authentication,
     it does not mean the client must do it.
     Especially strange client behaviour is that when the server
     does not advertise said capability, clients won't try to
     authenticate and just send message without trouble.

ESMTP is an option.  Not a requirement.

Is this more of a RFC 2476 issues?

   - When server does not advertise some capability in EHLO reply,
     client MUST NOT go ahead blindly and try to use it anyway.
     Blind AUTH attempts are common.

Isn't this a STATE machine issue?   This is covered I think.

   - There is only one (deprecated) case (port number), where
     in SMTP protocol extensions the TLS stream encryption is
     activated up front, in all other cases the processing
     follows STARTTLS specification.

RFC 2476?

  Following details have been seen to be escaping
  server implementers attention:

   - There is NO limit in the number of MAIL-transactions per
     single connection.  High-efficiency MTAs will send entire
     accumulated queue in as few connections as possible.

Ok, RSET considerations? Limits discussion for operators.

   - Requiring sender authentication at inbound MX servers for
     inbound message traffic is serious configuration mistake.

Expand please?   if I understand, we have a basic backward
compatibility issue:

     router (authorization required)
     final destination (no authorization required)

   - Server may need radically different service subsets at
     different ports, e.g. SMTP does not support STARTTLS, nor
     any AUTH, whereas SUBMIT supports STARTTLS, and different
     sets of AUTH depending on TLS being active or not.
     Non-standard plain-text authentications should not be
     available except under TLS encryption.

Ok, but these are pre-arrangements issues.

   - Servers don't separate DNS timeouts and SERVFAILs from
     genuine NXDOMAIN replies, and in all cases report permanent
     five-hundred series rejects, where proper is temporary
     four-hundred series retry.

Our server does separate the two.  I think this should be an excellent
discussion item.

   - Servers pay too much attention on EHLO greeting data,
     which from behind a NAT box may well be other than what
     the server sees.


If I understand you,  right now,  servers don't do anything with the client
domain name.   That's the key issue here IMO.

For our implementation, this is one of these reported reasons why some
operations turn off the domain literal checker, because they see one or two
false positives.  But at the same time, once they turn off it off,  they see
a higher increase of spam activity.

So in our experience, the problem is often reduced to white list issue since
the sender who might have this NAT/Firewall issue, is often known..

Hector Santos, Santronics Software, Inc.