ietf-smtp
[Top] [All Lists]

Re Anonymous Final Destination WAS : request discussion of two documents on SMTP relaying

2005-06-21 07:00:05



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

<snap>

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.


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.


I am trying to figure out what you mean by "Anonymous Final Destination"
(AFD) transactions

Is your opinion simply stated  "Do not send  bounce messages if you haven't
checked the MAIL FROM: or EHLO identity, only use  error replies during the
SMTP session"

Or do you mean something more sophisticated?
.
PS. I  do agree with this idea.
"If you cannot check the localpart directly, do not send bouncemail to
unchecked addresses."

But unfortunedly, it has nothing to do with mailsubmission, mailsubmission
in general doesn't happen at the receiving domain. and at the MSA (sending
domain) it is impossible to check the localpart of the receiving domain,
this would somehow go against the grain of SMTP, that relies on STORE and
forward.
This  would need the MSA to connect in directly to the receiving MDA for
checking the RCPT TO address, while  receiving the email. (so no storing at
the MSA)
But having said all that.
It doesn't imply that it is always impossible.

But maybe you wanted to say something different than I discribed above.




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