----- Original Message -----
From: "Willemien" <willemien(_at_)amidatrust(_dot_)com>
documents on SMTP relaying
I am trying to figure out what you mean by "Anonymous Final Destination"
(AFD) transactions
Authorized transactions, either explicitly or implicitly, implies the sender
is known by some BCP method in place. Typically a prior relationship is
established. In general (BCP), the only time authorization is required is
when the sender is attempted to do routing or relaying of mail. In this
case, when routing is request, authorization is required, this the
authorized session is not anonymous.
Since authorization is not required for final destination transactions, it
is anonymous in the sense that you are not required to perform any kind of
sender "checking" or "validation" to accept the transaction for a local
final destination message. You don't know if MAIL FROM is good or bad
until it is required to be used like in a bounce which will be too late in
regards to the spam spoofing problem, and for the growing eVirus problems
the worst mode of operation you can be in.
AFD is the top #1 reason for the spam problem. Spammers are exploiting the
huge network of machines behaving in AFD mode (as required by RFC standards)
where validation is not required and no taking place for final destination
transactions.
If a spammer was going to use your machine to route mail, it could only do
so authorized machine, in which case, it is not anonymous. The exception
to this is an open relay.
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"
No. I am not sure where that came from.
Or do you mean something more sophisticated?
Sorry, I am not sure in what context you are asking the question.
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)
Hmmm I think I understand your question now....
The receiver MTA will know the type transaction - Local Or Remote when the
RCPT TO address is provided.
If the address is local, that implies it is part of your local domains or
hosted domains if you are ISP. In this case, by best current practices, no
authorization is required. This is what makes the Internet work -
otherwise you will never be able to receive unsolicated mail from legitimate
people.
If the address is remote, that implies, this is not your under control, it
is not your domain that you own or are hosting. You can perform a check
to see if it really exist somewhere else, but that isn't typically done.
But either way, assuming the address does exist, it is not yours thus it is
a remote domain and the best current practice is to only allow this if the
sender is authorized to route mail.
This is what makes the internet work in our vast integrated public email
network that we have. If everyone had to be authorized to send local mail,
it wouldn't work very well.
In my view, the concept of ESMTP AUTH vs. 2476 (mail submission protocol - a
terrible name, but it is what it is) is either explicit or explicit.
Think of FTP. In FTP we have:
FTP Implicit SSL
FTP Explicit SSL
In implicit, we define a specific port that presumes a secured channel. In
explicit, the standard port is used and the client has the option to use
switch to a secured channel.
Same with SMTP.
ESMTP AUTH is an optional extended SMTP protocol. It is not required. This
is on port 25. This can viewed as Explicit ESMTP AUTH.
2476 at the top level is Implicit ESMTP AUTH because it is required. No
option. This is typically on port 587.
Now, I understand 2476 says you don't have to use port 587. Well, in my
view, that doesn't quite enforce it then. That's not the standard network
behavior.
Sure, you can probably have a dedicated machine that enforces ESMTP AUTH on
port 25, but than is certainly not the standard to do this and you certainly
will limit the email you can receive to a dedicated group of people only
that understand your this host on port 25 policy.
We have an option for ESMTP AUTH:
[X] Enable ESMTP AUTH
[_] Force for all connections.
If the sysop enabled this sub-option, then he effectively has prepared a
"closed" system. It can't be used for public internet.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com