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.
I am of a similar opinion - I think we need a whole set of what I think
of as "operational recommendations for email" (ORE would be a good
acronym) to improve interoperability between mail clients and mail
networks, and also to improve security, make the mail system more
reliable and its behavior more transparent, make MUA configuration more
uniform from one network to another, 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.
I'm not sure if I'm understanding you here, but I'm guessing you're
referring to the trend for MONs to require authentication (or some other
way of knowing who the originator is) but for MRNs to not require
authentication for messages for local recipients.
If I'm guessing right, a couple of points:
- port 25 blocking, whether you agree with it or not, tends to defeat
the ability for originators to send directly to recipient's MRNs.
- I believe that the ability to send anonymous mail is valuable and
there needs to be a way to do it, BUT there also needs to be a way for
recipients to distinguish anonymous mail from other mail, to impose
controls and quotas on it, etc.
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.
Compromised machines aren't the only problem - it has become very easy
for attackers to compromise the signal path between a client and server
and to introduce spoofing/man-in-the-middle attacks. This means that
any authentication method that doesn't provide data integrity and
server-to-client cryptographic authentication at a minimum, and probably
data privacy also, is easy to defeat - and attackers are doing just
this. So for instance any authentication scheme that relies on
"trusting" the source IP address is no longer reliable (this includes
both POP-before-SMTP and networks that "trust" their own addresses)
unless the _entire_ network between client and server is physically
controlled and _all_ of the routers in that network are filtering
traffic with that source address from other networks (which essentially
is never the case).
This is a real problem, and the only general solution is to move to
better authentication schemes. And it seems like exactly the thing that
should be addressed in this kind of document. This hole is perhaps not
currently one of the bigger enablers of spam, but it does enable spam,
and it would be confusing to have different documents provide
conflicting recommendations about authentication during email submission.
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.
There are lots of "email problems" :) Spam is just one of them.
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.
I suspect it's probably counterproductive to argue about which
particular path that spammers use is "the major exploit" - particularly
because spammers have proven to be very adaptable and have been able to
change their methods as countermeasures for previous measures were
deployed. To have an effective defense against spam and viruses it is
necessary to block _all_ paths. At the same time, any solution will
have to be deployed incrementally. The recommendations in spamops (and
my document) are useful steps, even if they don't completely block spam.
The main thing we have to keep in mind is that ill-considered measures
for blocking spam also end up blocking valid email and/or taking away
valuable functionality from the email system. So we need to make sure
that we make these recommendations with care.
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.
I disagree. We'd still have the same amount of spam that we have now
even if MRNs were able to authenticate the source of every message they
received. I'd even go so far as to say we're going to continue to have
massive amounts of spam as long as Windows is the dominant PC operating
system.
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.
We don't have a good system for solving this problem yet. At least the
last time I looked, SPF and IIM/DomainKeys were both extremely broken.
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.
Well, that depends on how you define the scope of the documents. If you
try to make the documents describe all of the ways to thwart spam,
you'll never get them out the door - there are too many paths to sending
spam and too many for which we don't have good solutions yet. OTOH if
you try to make the documents describe best known practices for
submitting and relaying mail (without limiting it to anti-spam measures
and without trying to be the comprehensive authority on all anti-spam
measures) this appears to be a manageable scope.
Keith