Keith,
First, I sincerely hope my comments are not taken in any way good or bad or
in any way a reflection on you or anyone else. I am just commenting with my
opinion. Also, please excuse my tendency of over simplifying problems and
solutions.
I reviewed both documents and I agree with you there needs to be more
clarifications. Overall, when I first read SPAMOPS a week or so ago, I
pretty much felt it covered the basic issues that are currently in place for
SMTP operations in "responsible systems." Indeed one of first thing that
did cross my mind was that it could use better rephrasing in certain areas
or better summaries, itemization in others. No big deal and given the fact
that it was authored by a team of prominent industry people, I trust all
work was done with careful thought and consideration even if I felt it could
of been done "better" here or there.
I think the documents (SPAMOPS and yours) are necessary in today's era and a
good start as a new requirements guideline and/or review of the current
operations for responsible systems. I think the document(s) should be
published to help as a new Mail Hosting Summary Requirements Guideline that
updates, supplements and/or augments RFCs 1123, 2476, 2505, 2821, 2822, etc.
However, with that said, the key problem with both documents is that none
of the documents clearly address the key issue of how to handle Anonymous
Final Destination Mail.
It may be out of scope, but it talks about making a clear distinction of
"WHEN" authorization is required, but it does not address what I believe is
the #1 problem with the "Email Problem" - when it isn't required.
The overall issue in Mail Hosting as it is related to TMS (Transaction
Management and Security) issues boils down to two fundamental key parts of
SMTP:
Current Legacy Normal SMTP (BCP) Operations:
1 - Authorization required for remote destination mail (routing)
2 - No authorization required for final destination mail (local hosting).
This is the essence of the Internet Email "Mail Flow" Distribution System -
it is the commonality of all systems. I believe the SPAMOPS pretty much is
describing this basic BCP.
As SPAMOPS writes, #1 includes all the current methods to determine
authorization, including
SUBMISSION protocol, IP relay table, ESMTP AUTH, POP B4 SMTP, etc. I don't
believe the industry is suffering as much here, however there is a new
growth of concern on how to handle compromised authorized user or authorized
MTA machines. But I don't think we can do much here but use a pattern
recognization and/or authorized routing limits policy. This is out of
scope for SMTP I believe however, I reserve there might be a feedback
concept to be reviewed.
The "Email Problem" (Spam or Spoofing) begins pretty much with #2. This is
where over 60-80% of the problematic mail issues begin. It the basis for
the key abuse and exploitation of SMTP.
I like to call #2 as "Anonymous Final Destination" (AFD) transactions
because for the most part, the major exploit in SMTP is that there is no
requirement to "verify" the sender for reception of local user and/or local
hosted domain transactions. Therefore, the sender is "anonymous" in the
sense it is not verified nor there is a requirement to do so for final
destination mail.
In other words, systems adopting the documents can most certainly help
people run a better server, but it doesn't change or address the fundamental
problem where there is abuse or non-compliance with the transaction
parameters. If it did, then we would not have the "Email Problem" today
to the tune by current estimates of $13-15 billion industry cost.
In short:
We don't have a problem with GOOD systems. We have a problem with
BAD systems that we can't get control or handle on.
SPAMOPS pretty much says:
Make sure your server knows when final vs. routing is taken place, and
to enforce an authorization policy for routing.
I think the key consideration in SPAMOPS is the encouragement to run a
dynamic SMTP RCPT validation system as opposed to a post SMTP RCPT
validation system. The good news in my perspective is that most good
systems do perform a Local RCPT validation. I base this on our CBV
operations.
But what it doesn't say is how to handle the "verification" of the
transaction or mail sender when a valid FINAL destination is finally
determined. RFC 2476 is ok, but that is not where the problem is located -
it is located with anonymous final destination senders.
Anyway, some might be believe this is out of scope for the documents, but it
is a critical aspect of the mail distribution problem we are trying to
address. So at a very least, this needs to be discussed at some level in
the documents.
To me, the future of SMTP and its TMS will largely depend on how we want to
address Anonymous Final Destination mail from several standpoints:
- Verification of process entities with/ minimum SMTP compliance.
- Extended SMTP Response Codes to help admins define better automated flows,
(white, black, grey listing).
- New R&D on extended SMTP commands, like HEAD to assist new
"Blast First" PAYLOAD email security protocols.
- New R&D on extended SMTP client/server handshaking requirements to
help define optional transaction compliancy policies.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
----- Original Message -----
From: "Keith Moore" <moore(_at_)cs(_dot_)utk(_dot_)edu>
To: <ietf-smtp(_at_)imc(_dot_)org>
Sent: Wednesday, June 15, 2005 4:55 PM
Subject: request discussion of two documents on SMTP relaying
Folks,
Some of you may not be aware (especially if you're not subscribed to the
IETF list) that there's a document in Last Call for BCP,
draft-hutzler-spamops-04, that makes recommendations for submission of
mail and relaying of mail between mail networks.
I don't believe that this document is written with either adequate
precision or accuracy, and frankly I didn't see any easy way to fix it
by making small changes to the text. So n an attempt to produce better
language, I wrote my own draft of a document with similar scope, which
can be accessed at
http://www.cs.utk.edu/~moore/opinions/email-submission-recommendations.html
I also believe that this topic needs more discussion among SMTP
implementors and users before any document can claim to have rough
consensus.
I would therefore appreciate it if members of this list would read both
documents and offer comments about either or both of them, particularly
about areas where the two documents differ.
I'll also send a copy of my Last Call comments to this list, in a
separate message.
Keith