Keld Jørn Simonsen wrote:
On Wed, Feb 11, 2004 at 04:57:19AM -0500, Bruce Lilly wrote:
Your first suggestion conflicts with RFC 2821.
I think it would be OK to check it with the original receipt, or at the
final receipt. So "always" was not directed towards any intermediate MTAs.
Would it then still be in conflict with RFC 2821? Which section?
The conflict regards delaying the error return for invalid recipient
until after DATA (RFC 2821 section 3.3). See the paragraph near the
bottom of page 18 beginning with "However, in practice".
The paragraph which follows that one makes it clear that an SMTP
server isn't supposed to grope about in the data (message), but is
simply supposed to transfer it based on envelope information. It
is probably OK for a server performing final delivery to do so. It
is more difficult for a plain SMTP server to determine if it is the
first MTA to handle a message, though a server using the submission
protocol (RFC 2476) could make such an assumption.
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).
I did not mean to especially use 551, but a new code such as 555.
My idea was to get rid of all these different error messages
that I have tried to list in my filters. I have collected more than 300
different
messages essentially for the same thing. I think there should be a new
response error code just for this:
555 - we do not accept virus or spam here.
554 is too vague for the reason.
The text following a 554 response can be embellished. Ideally any 5yz
response other than the ones specifically mentioned in 2821 should only
be used if some suitable ESMTP extension is negotiated. There may be
some old SMTP clients that do not handle any codes other than the
specified legal ones correctly.
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).
Well, I wanted as final receiving MTA to discard the message, the sender
address is bogus anyway.
Not necessarily -- your virus/spam detector might have provided a false
positive to legitimate mail with a valid sender envelope address. Once
an intermediate MTA has issued a 2yz response to DATA and subsequently
encounters an error on transfer to a downstream SMTP server, it is
obligated to send a non-delivery message to the specified sender envelope
address (if not null).
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.
Plain SMTP transactions are rare, almost all transactions that
I see on my mail server are ESMTP. SMTP is under 1 promille.
That might be true for legitimate mail, but you can't prevent a
spammer or virus author from using HELO rather than EHLO. Servers
MUST support HELO (2821 sect. 4.1.1.1). Not all clients or servers
that support some ESMTP extensions support all extensions.
I understand that almost the same amount of error mail will be
generated. The idea, however, is that the receiver of the error
mail will have a much better understanding of which kind of error mail
it is
That should be clear if a delivery status notification (DSN) is used.
If a DSN is not being used, either plain SMTP is being used or the
DSN extension is not supported.
Another way to handle some of this is to have RBLs of infected
machines, and then reject/discard the mail upfront.
How do you propose to identify such machines? IP address won't work
(DHCP), and domain names won't work (easily forged). How do you
propose avoiding yet more collateral damage? How do you propose
removing a machine from an RBL when it has been cleaned?
I use general rejection of .exe .pif .scr .com etc extentions,
this really catches most of the virus. And I really cannot see
a valid reason for sending these attachment types by mail,
which cannot be done in another more secure way.
Those are not "types", they are names. A text file discussing a
particular domain or the company it represents might very well
have a name ending in ".com". Moreover, the virus writers are already
ahead of you; they are now packaging their payloads as compressed
archives (e.g. test.zip).
I think that the updated antivirus info generally gets widely
distributed in about a day and a half. So yes, the virus have about that
time to disseminate. Still we see MyDoom and other vira floating around
a long time after that outbreak period. This could be stopped.
It won't stop as long as there are machines with gross fundamental
security flaws and incompetent users. Code Red is still active...
Another way to limit the outbreak (or incumbination?) period is to
apply RBLs for the infected machines.
See above.
This would give a much shorter
time, as antivirus info is something that is distributed and fetched by
the individual users on a daily basis
Which users? There are users who have no AV software installed and
there are others who haven't updated in literally years.
RBLs are also cheaper to employ as the mail can be discarded upfront,
But they unacceptably cause legitimate mail to be discarded.
Yes, here RBLs would also be a bonus.
Anyway just discarding mails with attachments of said types would
get you almost all of the virus.
You cannot determine a "type" by a "name"; they are two unrelated
things.
Yes, you may have a point there, I have not looked into that specific issue
of how stable the ip addresses of infected machines are.
Anyway that would then reflect on the ISPs that they have spammers
or virus infected machines among their customers, and then it is the
ISP's problem to avoid that.
Most ISPs do have customers with infected machines. How do you propose
that they prevent that?
If you have a machine with a fixed ip-address, however, then there
would not be any problem for that MTA. And MTAs on dynamic IP is
questionable anyhow.
Not all SMTP clients are MTAs (RFC 2821 section 2.3.8). MUAs can be SMTP
clients, and an MUA on a machine with a dynamic address (like this one)
is not at all unusual.