----- Original Message -----
From: "Daryl Odnert" <daryl(_dot_)odnert(_at_)tumbleweed(_dot_)com>
To: "'Hector Santos'" <winserver(_dot_)support(_at_)winserver(_dot_)com>
Sent: Thursday, March 25, 2004 5:49 PM
Subject: RE: Do the must 'bounce' rules need to be relaxed for virus infec
Yes. I agree that in the context of this discussion, it is more
if an SMTP server is able to reject an undesirable message during the SMTP
It is not a matter of convenience but of necessity. It does three things:
1) It help shoves this fraudulent mail spoofing issue,
2) It reduces your mail loads by atleast 200-280%,
3) It removes the burden you place on others.
But why should the SMTP protocol preclude server
implementations from performing local policy analysis after the message
been accepted from the client?
As a product developer and vendor, we have no choice but to provide both
mode of operations. So I can understand why this is being proposed. I am
not against the concept in principle. I just think we need to be careful
that it doesn't open a can of worms when there is a better ways to solve the
problem legally and with great success.
However, it is an old legacy mode of operation, unfortunately still used in
mass today - hence the spoofing bounce problem the sorbig generation virus
exploit for their dual mode distribution logic.
The mode doesn't work well today and we recommend that in our documentation.
We have customers coming out of the wood works nearly every day saying "how
can they stop this spoofing bounce problem." Well, the first we check is see
what mode they are running under and quite often they simply didn't know
their SMTP server was integrated with the backend directly and there exist
new options for SMTP validation. When disabled, it reverts to old
operations where SMTP receives everything and depends on the gateway to
handle the export, import, routing and/or bounce logic. An extremely high
overhead mode of operation which in todays spam environment can account for
over 80% of your mail bounces.
We havn't found one customer that gave a good reason why they had to
continue to operate in this old mode. It wasn't scalarbility reasons.
Even AOL, the "biggest ISP" does RCPT validation. Why can't smaller systems?
Anyway, from a design standpoint, my main concern is that we risk going
down an unethical slippery slope once be begin to change the idea that the
acceptance of mail has no reliability and responsibility behind it. Think
about it. What is "malicious and deceitful" to some, can be plain old
censorship to others. I don't think it is a good idea to have a new can of
worms of using "fuzzy mail interpretation" as a way to drop mail into
SMTP acceptance/rejection should be a technical compliancy related issue. I
think that is where we ought to be focusing. Having AVS systems will always
be there after the fact, and in a growing amount of systems at the "DATA"
stage keeping mail content-based rejection at the protocol level, but the
general bouncing issue can be solved at SMTP. If you allow the AVS logic to
do it after SMTP, then we run into these issues we have today.
Finally, this is all further evidence that SMTP needs to be modified whether
the DATA is split into two commands:
It will address everything we been discussing in the many different
ANTI-SPAM related channels.
1) Mail From/Helo Spoofing,
2) Better LMAP operations, solving the forwarding problem,
3) New proposals which inevitably will put bandwidth pressure on the
industry (YDK, MCEP),
4) CANSPAM by satisfying both mandates (valid return address and topic
4) a peace and harmony with the dual philosophies of dynamic vs post smtp
Plus everything else it will solve by having the envelope and network
traffic information upfront, thus keeping mail transport
acceptance/rejection at the protocol level.
Hector Santos, Santronics Software, Inc.