[Top] [All Lists]

Re: Re: Re Anonymous Final Destination and mail submission

2005-06-25 07:16:08

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

Authorized transactions, either explicitly or implicitly, implies the
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.

That's what I meant
If you do not know if the  MAIL FROM is good or bad do not use it.

AFD is the top #1 reason for the spam problem.   Spammers are exploiting
huge network of machines behaving in AFD mode (as required by RFC
where validation is not required and no taking place for final destination

It is more the problem that bounces are used in an inappropriate way.
Bounces should (in my opinion) only be send:
- if the mail domain is invalid /unreachable
- after a bounce reply (SMTP 5xx error)
- maybe some other situations not

Bounces should NOT be send:
If the MDA after accepting the email, finds that it cannot deliver it.
(The MDA should not accept the email in the first place)
maybe an exception here for large ISPs and large organisations
Emails containing virusses, expecially do not bounce the virus back.

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
checked the MAIL FROM: or EHLO identity, only use  error replies during
SMTP session"

No.  I am not sure where that came from.

It was just my (maybe to) simple conclusion of the whole AFD problem

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,
in general doesn't happen at the receiving domain. and at the MSA
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
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
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,
authorization is required.   This is what makes the Internet work -
otherwise you will never be able to receive unsolicated mail from

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
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
it wouldn't work very well.

In my view, the concept of ESMTP AUTH vs. 2476 (mail submission protocol -
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.
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.
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

Sure, you can probably have a dedicated machine that enforces ESMTP AUTH
port 25, but than is certainly not the standard to do this and you
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.

I think the MSA works different from your idea of an MTA.

In the following I make a distinction between posting == submission and
mailing == getting the mail to its (external) destination.
(sending is not used)

First of all:
The MX dns records should NOT  point to an MSA so  mail from anonymous
/external users should not be  mailed  to an MSA. If  (by lack of hosts or
something similar) the MSA and the MTA have to share an IP address the MTA
gets port 25 and the MSA gets port 587)

MSA should know their clients, there need to be a prior relationship, and
the clients (MUA) should  post all there emails to just one host (MSA) .
(the smarthost principle)
The MSA checks if the client is allowed to mail emails and then mails the
email over the internet.

For LAN's there is no need to use port 587, local users (MUA) can post to
the MSA just over port 25. again without using MX records.
Some even think that all LAN users are by definition authorised to mail
trough the MSA so in this case there is no need to authorise.

Roaming users  post there emails to the MSA by using port 587 (preferably)
or port 25, again the MSA checks if the user is authorised and if so, mails
the email towards its destination.
Here port 587 is also chosen because some ISP's (for their reasons) block
traffic on port 25 that is not directed to their SMTP servers.

A curiosity exists, what if a unrecognised client posts mail for a known
local user.
An MSA should /can reject the email  while an MTA MUST accept it.
But this is al a bit  beyond the discussion, if it was only because
unrecognised clients will mostly use the MTA (with MX pointing to it) in
preference to an MSA, (without MX pointers)

MSA can be seen as just  a major extension of ESMTP AUTH. with using a
different port to reduce the double usage of port 25 but there is a bit more
behind it.

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