----- Original Message -----
From: "Martin Stecher" <martin(_dot_)stecher(_at_)webwasher(_dot_)com>
To: <ietf-openproxy(_at_)imc(_dot_)org>
Sent: Wednesday, February 02, 2005 11:33 AM
Subject: RE: Activation points and callout modes
And I assumed that most MTAs maintain something like queues in order to
store the messages they receive before they forward them (or maybe to
store
if they cannot forward immediatly).
But I may be wrong.
As Tony mentioned, it is pretty much a design requirement to queue your
outbound mail. Undeliverable may must be bounce after the specific system
policy of "retries" is exhausted. Simply throwing them away would not be
viewed as an acceptable
operation. Of course, a growing number of systems (I say isolated small
operators) are adding filtering to the mail so it is quite conceivable that
mail can be throw away. However, it is still a standard practice to bounce
undelivable mail that was accepted by the SMTP process. If a transaction is
rejected at the transaction level, then no BOUNCE is required.
The idea is simple:
The expectation of deliver or the reasons for rejection is naturally
expected by the user. This is legal precedence for this in covered by
provisions in US ECPA governing "user expectations." A dynamic rejection
provided the instant notificaiton. If the SMTP accepts the message, the
either delivery or a delay rejection notification is expected. This is
based on the original non-store and forward Online Mail Hosting days, where
users were online creating messages: Once the user press the "Save" button,
the system either accepted it or rejected it immediately for some policy
reason. To accept the message and never make it deliverable or readable,
constituted a form of censorship.
This changed in 1998 with the USCA Section 230 provisions passed by Congress
that now give ISP for the most part, a near 100% immunity in areas of
content editing, including having editorial power to not post the user
message at all. However, there is still a good samaritan provision in 230
in honoring user expectations.
Even with a PROXY concept here, I believe it still needs to follow the
current SMTP design expectations. If the OPES device is implemented at the
DATA stage, this falls in line with the "instant notification" concept
satisfying the user expectation. If the OPES device accepts the message,
then I believe it is now the SMTP operator responsibility (ISP) on what he
will do with the message.
Has anybody a clear view on how many MTAs (percent of real world
deployment)
can only work in a non-storing proxy mode (only accepting a message if
they
already successfully forwarded to the next MTA in a parallel SMTP dialog)?
That wouldn't make sense. A SMTP proxy design can not break the expected
operations of a normal SMTP server. It wouldn't be a good proxy if that was
the case.
And how many MTAs do always store a message before forwarding?
All of them.
And how many try a direct forward and store only if that does not work
out?
Yes and maybe no. This may depend on the features of the SMTP router.
By design, most, if not all, will go directly to the EMAIL address MX host.
The basic rule of thumb is this:
1) Get the DOMAIN of the email address (example.com)
2) Lookup the MX record(s) of the domain example.com.
2.a) This will provide the list of IP address to try to connect to. So for
example, if the MX records result in
10 IP addresses, then each one is tried in a round robin fashion. If the
first IP fails, it goes to the next
and so on.
2.b) If the domain has NO MX record, then the basic rule is to use the A
record of the domain and try atleast
1 time to connect to the remote mail host server.
So to answer this question.
Yes, if there is an MX record.
Maybe no, if there is no MX record.
It could be that the DOMAIN results in a NXDOMAIN which is a no-domain exist
in DNS. This could
be a candidate for an immediate "try once" only.
But it depends on the sysop and the features offered by the SMTP software.
If DNS is down or your internet connection is down, you certainly want to
requeue this until DNS/network is back up.
Sincerely,
Hector Santos, CTO
Santronics Software, Inc.
http://www.santronics.com
305-431-2846 Cell
305-248-3204 Office