I tried replying yesterday, but for some reason only a blank message
showed up on the list.
Unfortunately I did not keep a copy of my original message, so I have
to try to recreate some of the points from memory.
As I have mentioned before, my area of expertise is viruses and worms.
For that reason any proposal which is likely to affect the spread of
worms as well as spam is of high interest to me.
I just read the draft-irtf-asrg-mtamark-00 document, and I have a few
comment on the virus/worm side of things.
The document uses the term "viri". Now, there is an interesting
division of terminology in the anti-virus field. AV people use the
plural "viruses", while the "k00l VXdudez" use "viri" or "virii"
as a means of distinguishing them. The side effect is that anyone
talking about "viri" or "virii" just does not get taken seriously
by the anti-virus community.
However, MTA MARK would not have any effects on viruses. It would
only affect worms, more specifically a certain subset of worms. It
would not affect network worms like CodeRed, so I suggest not using
that as an example. It will only affect those worms which have
their own SMTP code and use that to spread, instead of sending mail
through the ISP of the end user. By far the best known worm of
this time is W32/Sobig(_dot_)F(_at_)mm(_dot_) I suggest not mentioning viruses
(or
"viri" or whatever) in the document - only worms, as only they would
be affected.
Now, an observation:
During the Sobig.F outbreak we collected data on which machines were
responsible for sending out the viruses. It turned out that the vast
majority of analysed samples were from privately owned PCs with an
ASDL or broadband connection. This is what one would have expected
anyhow - corporate machines are generally better protected and less
likely to be compromised and machines with only a (slow) modem
connection would send out fewer messages than the ones with a fast
connection.
The relevance to spam is that this is presumably the same group of
machines as spammers using compromised machines would be interested in.
I raised the point of comparing this to simple port 25 blocking, but
someone else brought that up as well, so I have no further questions
regarding that.
However, MTA MARK got me thinking about one issue regarding LMAP
(which, by the way seems to be mis-spelled as LAMP in one or two places
in the LMAP document).
If I understand LMAP correctly, you can get basically 3 possible
answers:
"This machine is authorized to send mail from my domain."
"This machine is not authorized to send mail from my domain."
"No LMAP data available."
(somebody please correct me if I am wrong). Now, the MTA MARK proposal
made me realize that the "not authorized" includes two separate
scenarios, which might require different reactions:
"This is one of my machines, but it is not authorized to send mail
from my domain" - this result would typically indicate a compromised
machine - either trying to send out worms or spam.
"This is not one of my machines, and therefore it is not authorized
to send mail from my domain" - this result would either indicate
a forgery or perhaps a "roaming salesman" instance.
What I don't quite see is how LMAP would distinguish between those two
cases - or if it can indeed do so. Clarification, anyone?
--
Fridrik Skulason Frisk Software International phone: +354-540-7400
Author of F-PROT E-mail: frisk(_at_)f-prot(_dot_)com fax:
+354-540-7401
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg