[Top] [All Lists]

Re: request discussion of two documents on SMTP relaying

2005-06-18 09:55:53

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

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

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.


<Prev in Thread] Current Thread [Next in Thread>