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
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
The "Email Problem" (Spam or Spoofing) begins pretty much with #2. This
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
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
In other words, systems adopting the documents can most certainly help
people run a better server, but it doesn't change or address the
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
it is located with anonymous final destination senders.
Anyway, some might be believe this is out of scope for the documents, but
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
To me, the future of SMTP and its TMS will largely depend on how we want
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
(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"
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
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
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
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
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.