On Wed, Feb 11, 2004 at 09:18:42AM -0500, Bruce Lilly wrote:
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".
OK, I will (did not do it yet)
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.
For what I describe, it is only necessary to do it at final delivery,
when this is permissable anyway. My idea is to swop the check for bad
data with the checks for valid user and mailbox overflow and such.
This would then reduce the amount of error messages for 'no such user'
or 'mailbox full' - as these errors for the bogus mail will be
eliminated.
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.
Well, it could be handled in another way, as also described in response
to Hector.
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).
Yes, false negatives are always something to consider. But they will
happen anyway (with current spam technology such as spamassassin).
A very small error rate is tolerable, at least to me.
I am not talking about intermediate MTAs, only final delivery.
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.
Yes, spammers may use HELO. But do we care for spammers?
I don't:-) So we need not treat them well...
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.
Hmm, I don't think we have seen spammers use DSN yet, but they may do,
just to increase the chaos they generate. Then however, if we have
determined that the mail is spam or virus, I think we should not honour
any additional requirements the sender has asked us to do. The mail is
malicious, and we cannot trust anything in it - the best thing
we can do is to discard it.
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?
IP-addresses would be my choice of identification.
I would not guarantee dynamic addresses to be able to run an MTA.
Removal of the blocking could be done just by some web interface,
However, it should not be doable by software, only by manual
intervention.
Some thoughts should be done to caveats, I am not fully sure if it would
work, but would like to see it in action. How do those professional
firms do it, that sell such blacklists? And there are projects that
already does this RBL service, although not well maintained.
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).
True, they are names. But then people should avoid names like ".com".
And yes, they use .zip - to me that means that .zip files are not
useable anymore on the net. We have to adapt to this hostile world,
and not sending .com or .zip files is one of the small offers
we may need to do. That is a very minor cost in my eyes.
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...
You are right, but we could stop them from arriving in our mailboxes,
at least in the more knowledgeable users mailboxes (including the users
that are wise enough to choose the right ISPs). What I describe does
avoid code red and MyDoom to arrive in *my mailbox* and even others
bogus error mail that *I* sent them virus could be avoided in my own
mailbox. That is, I think this could be the result, but I invite others
to analyse whether that is true.
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.
True. But there are also other users that do update their AVS on a daily basis.
And you get what you deserve if you dont protect yourself against virus.
RBLs are also cheaper to employ as the mail can be discarded upfront,
But they unacceptably cause legitimate mail to be discarded.
Yes, that is a risk, that we should minimize.
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.
In principle you are right, but in practice it works fine.
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?
One idea is that the customer on a dynamic IP always should use the MTA
of the ISP - who then does proper scanning of incoming mail for virus
and spam. If the dynamic IP customers don't, then good luck! For static IP
customers, well they better not be sending spam/virus - but if they do,
they would only hurt themselves.
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.
Yes, dynamic IP SMTP agents are not unusual. I once did that too, but
now I got a fixed address ADSL for my home machine.
Anyway what do you propose for such animals?
What about your ISP, do they not provide you with a mail relay service?
Most ISPs do.
Best regards
keld