Keld Jørn Simonsen wrote:
I would advice that we recommend some best practice procedures,
hopefully to be implemented in the MTAs software products of the world.
Maybe we should write an RFC on this.
I have got three pieces of advice:
1. Always check for virus/spam before checking for valid reciepient, or
whether the mailbox is full or some such.
Checking recipient can be done at the time of RCPT TO. Checking for
a virus can only be done after the body has been collected (end of
DATA). RFC 2821 discusses difficulties that arise if rejection due
to invalid recipients is postponed until after DATA. Checking body
content is only appropriate at initial (submission or first SMTP server)
or final stages of delivery -- an intermediate SMTP transfer is supposed
to be transparent to the data, and intermediaries have no business
making policy decisions for distant senders or recipients [of course,
there shouldn't be any intermediate relays except in unusual situations
(N.B. there may be intermediate servers as noted below which are not
relays, they are responsible for the sender's or recipient's mail domain)].
Your first suggestion conflicts with RFC 2821.
2. Generate a specific error message, maybe we should introduce a
standard error code for this, like 551 - mail rejected as virus or spam.
551 is reserved for "user not local". 550 is the error code for rejection
for policy reasons, but is not listed as valid after DATA. 554 (transaction
failed) is valid after DATA.
So here's another conflict (though returning 554 would be acceptable).
3. If the mail is virus or spam, then do not send it back to the
sender - as this is most likely a forged address anyway. Discard it
instead. But if you must, then use the standard error mesaage as
described above.
If SMTP were still universally used as intended (i.e. sender's MUA
connects to recipients SMTP server), that might work. However, in
practice there is usually some intermediate SMTP or submission
protocol server. If rejection takes place during final delivery,
an intermediate server (now acting as SMTP client to final delivery
SMTP server) has no choice but to send some sort of non-delivery
message (RFC 2821 section 4.4).
So in many cases, there will still be a non-delivery message, and
in the absence of some means to verify authorization to use the
specified sender envelope address, such messages will continue to
cause collateral damage. [E]SMTP AUTH provides authentication, but
as it is an extension, it can do nothing for plain SMTP transactions.
While there's no conflict, in practice your third suggestion will
have limited effect.
I think with this scheme, we would have avoided alomost all of the
virus/spam and also annoying error traffic .
Maybe. But that's already history. There are plenty of open relays,
and so long as there is at least one, any future virus/worm could
use that relay, and the payload would be delivered (either to the
intended recipient or to the forged return address). Likewise for
spam. Closing open relays is therefore a prerequisite to successful
implementation of any scheme such as you have proposed.
No need for new protocols, closed networks etc. Maybe a need for some
RBL listing virus/spam infected machines, I don't know.
Aside from the need to close open relays and the need for verification
that the specified sender envelope address is appropriate, there are
other issues that make your scheme impractical. Scanning body content
can only take place at the end of DATA during acceptance (or rejection)
for delivery. The minimum timeout for a response at end of
DATA is 10 minutes. Assuming all clients waited for at least that
long (some do not), that timeout imposes an upper limit on the
amount of time available for processing to determine whether or
not there is a basis for rejection on policy grounds. If a large
number of simultaneous connections are being handled by an SMTP
receiver, that may present an unacceptable processing burden.
From a practical point of view, anti-virus signatures generally only
come out after a virus has propagated fairly widely, so for some
time after a virus is unleashed it will be delivered undetected even
by those who keep their AV software up-to-date. The same considerations
(must take place after DATA is complete at final delivery SMTP
receiver, requires processing overhead, arms-race considerations)
apply to spam.
In the case of virus content, it's difficult to justify requiring a
site with no Microsoft platforms to install, maintain, and operate
anti-virus software due to poor design of Microsoft products and/or
inadequately trained or incompetent users of same. One generally
doesn't allow toddlers to operate plastic tricycles on busy highways;
likewise those not competent to practice minimal security and those
whose systems fail to meet some minimum security standards shouldn't
be allowed on the "information superhighway" (apologies for
resurrecting that tired cliché). An RBL is unlikely to work; the
existence of ISPs that use a pool of IP addresses for dialup and
broadband subscribers via DHCP means that IP addresses cannot be
used to identify infected machines -- one minute a particular IP
address might be assigned to a virus-infected machine running an
insecure operating system and operated by a clueless user, and the
next minute it might be assigned to a firewalled system operated
by a security expert. If there's an answer to this aspect of the
spam/virus problem short of universal IPv6 deployment and static IP
addresses everywhere, it will probably have to be a policy/licensing
(analogous to a driver's license) matter rather than a purely
technical solution.