North American Network Operators Group|
Date Prev | Date Next |
Date Index |
Thread Index |
Author Index |
SMTP store and forward requires DSN for integrity (was Re:Clueless anti-virus )
- From: Douglas Otis
- Date: Fri Dec 09 10:38:37 2005
On Fri, 2005-12-09 at 09:25 +0000, Simon Waters wrote:
> But the point of this discussion is that SMTP will have to evolve to be a
> point to point system (or functional equivalent). The days of store and
> forward in intermediate MTAs should die as quickly as possible (which as our
> forwarding demonstrates may be quite slowly alas). The problem is that many
> of the antivirus gateways behave like new intermediate MTAs, especially when
> for many of the organisations involved it could easily be done during SMTP
While AV scanning may be done during the session, it would also require
additional steps to also contain _all_ upstream activity within the same
session as well, when attempting to achieve an apparent point-to-point
operation. If SMTP were point-to-point, this would be evolving into the
IM model where the message queue or storage would always be at the
sender. Such mode of operation will increase the average transaction
time needed for email.
As SMTP may pass messages through multiple administratively separate
MTAs where acceptance criteria may differ, unless all connections needed
to complete the transaction are active simultaneously, refusal at any
point will require use of a DSN or delivery integrity is lost.
A common exploit used by abusers is to find where acceptance criteria
differs between MTAs. Abusers depend upon this to generate DSNs that
act as a delivery vehicle of abusive messages masquerading as DSNs with
spoofed return-paths. While simulating point-to-point operation would
be one (expensive) approach at solving this problem, some have suggested
the use of SPF records to qualify the return-path before accepting the
The qualified return-path approach has several problems. It may require
more than 100 sequential lookups to fully resolve a complete address
list, which is often open-ended. These address lists remain open-ended,
as there are many legitimate cases where this qualification still fails.
As of yesterday, there is no record in use with a scope specifically
defined to qualify the return-path.
BATV on the other hand solves the DSN exploit without waiting for anyone
else to adopt some practice. Although there is a small window where the
BATV return-path could be replayed, such illegal activity can be traced.
Neither Sender-ID nor DKIM will solve this serious exploit either.
While many AV products are a nuisance as they enable this DSN exploit
which actually spreads viruses (#$%&*), solving this problem does not
require changing the nature of SMTP and dramatically affecting every
email system, or even hoping everyone qualifies the return-path prior to
acceptance. BATV is really a simple and effective solution that should
be put in place now.