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 transactions.
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 message. 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. -Doug