Subject: Re: [Asrg] Re: 6. Proposals: LMTP vs. rDNS / Reverse MX [RMX] proposals

From: "Tomi Panula-Ontto" <[email-masked]>
Date: Mon, 1 Dec 2003 16:56:40 +0200

On 11/30/2003 1:00 AM, Matthew Elvey said:

----- Original Message ----- 
From: "Matthew Elvey" <[email-masked]>
To: "Tomi Panula-Ontto" <[email-masked]>
Sent: Sunday, November 30, 2003 1:00 AM
Subject: Re: [Asrg] Re: 6. Proposals: LMTP vs. rDNS / Reverse MX [RMX]
proposals

> Reply below.  Please reply to the list, quoting me.
> On 11/29/2003 12:11 AM, Tomi Panula-Ontto sent forth electrons to convey:
>
> >
> >[cut]
> >
> >
> >>>Also, I don't like parsing TXT records (Parsing == bugs == troubles).
> >>>Bind and Tinydns seem to differ in TXT records, too. Some Bind versions
> >>>send extra character (space or ") (parser bug?) whereas Tinydns
doesn't.
> >>>Conclusion: I'm against TXT records.
> >>>
> >>>
> >>A bug in the TXT part of software that has known security holes and MUST
> >>be replaced anyway isn't a deal breaker, IMO; I'm assuming these bugs
> >>are only in old versions.
> >>
> >>
> >
> >It's easy to say "must", but lot harder to get all the servers upgraded.
> >It isn't deal breaker; MTAMark has very good qualities (and I think I had
> >a little misunderstanding on my side here about it).
> >
> >
> So you are no longer against TXT records, yes?
>

I'm still against both TXT record and parsing.
I don't like the idea of receiving multiple ASRG.<PARAMETER>=<VALUE>
that I'm supposed to parse and make the decision.
I want to keep things simple.

The original reverse mx proposition suggested that we should have
a list of IP addresses [=authorized/trusted MTAs] for a given network.
Scenario: "IP is listed => Allow"
Scenario: "IP not listed => Deny"
Scenario: "IP not listed (no list) = Work as before (Allow)" (Deny if timed
policy change?)

MTAMark was in this sence a bit better; instead of getting the LIST of IP
addresses (and using multiple dns queries) there would be one simple answer;
ASRG.MTA=YES or ASRG.MTA=NO - so there is no need to determine
whether the network admin has done the job.

Reverse MX proposition has been updated after this.

4.3.2.1.in-addr.arpa IN PTR mail.company.dom.
4.3.2.1.in-addr.arpa IN MX 10 127.0.0.2

127.0.0.2=Allow, 127.0.0.3=Deny

(I'd say priority field should be reserved and should be 10, any comments?)

If one wishes, it's still legitimate to inform reason (or whatever)
in TXT record

4.3.2.1.in-addr.arpa IN PTR dialup-127.company.dom.
4.3.2.1.in-addr.arpa IN MX 10 127.0.0.3
4.3.2.1.in-addr.arpa IN TXT "DIALUP"

There is a record type for this purpose, so why not use it?
Why invent a system on top of a system?

> I suppose it might make RBLs need fewer entries.  But should my ISP, a
> common carrier, have any business deciding whether or not I should be
> able to run a non-abusive mail server?  I'd rather they not, when the
> benefit is a very slight impact on spam that can be achieved without
> such restrictions.  I prefer to have RBL runners in control to ISPs in
> control, but I guess that's a political question.  I'd most like to have
> LMTP in control.

Fewer entries? A LOT fewer entries. No more spamming from dialups,
or from unauthorized IPs, etc.

Are you saying that if this MTA registering would be mandatory
to the network owners and receiving MTAs would start using it
it would not cause any or irrelevant amount of reduction in spam?

It's LOT easier to spot bad behaving IP addresses from a set of
500 000 registered MTAs than from a set of approx. 4^32 (not to mention
IPv6).
It gives us a more control; the network abuse team can block it and if they
don't or do it late, we can still RBL the spammer out.

Your network provider (aka. reverse zone administrator) should ask
you "Hey, in order to fight solicited email, we have to register all MTAs.
What's your MTA IP address?" You give them your IP(s), they add
it to the dns and everybody should be happy.

Then, go ahead and generate spam as much as you wish, but don't
come wondering what happened when your network abuse team
unauthorizes your MTA IP address for spamming.

We need rules. One rule would be that you will have to register your
MTA with your network provider. I do know some networks
would propably set every IP they got as trusted IP - and we'll be
happy to RBL them away.

This is a little change, little check, which is easy to maintain and
easy to develop support for it. If there are no major problems with
it, then why not?

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: "Mark E. Mallett" <[email-masked]>
Date: Mon, 1 Dec 2003 10:23:03 -0500

> 127.0.0.2=Allow, 127.0.0.3=Deny

BTW (and I was guilty of this the other day too.. but didn't occur
to me until a little after posting): the target of an MX is a name,
not a number.  "127.0.0.2" can be used, but it doesn't mean an IP
address.  Perhaps some use could be made of the reverse MX pointer
indicating some legitimate name.

mm

---

From: Yakov Shafranovich <[email-masked]>
Date: Mon, 01 Dec 2003 17:45:55 -0500

Tomi Panula-Ontto wrote:
[..]
> easy to develop support for it. If there are no major problems with
[..]

The DNS folks over at the IETF might be able to answer this question 
better since any use of the reverse DNS space involves different issues, 
on which we do not necessarily have the expertise. We will try to pass 
on the draft for review if feasible.

Yakov
-------
Yakov Shafranovich / asrg <at> shaftek.org
SolidMatrix Technologies, Inc. / research <at> solidmatrix.com
  "Why are both drug addicts and computer aficionados both called 
users?" (Clifford Stoll)
-------

---

From: Matthew Elvey <[email-masked]>
Date: Sat, 06 Dec 2003 08:45:15 -0800

>Why invent a system on top of a system?
Well, for one thing, I fear people like me (one static DSL IP on SBC) or 
using dyndns on a dynamic IP are unlikely to be able to convince their 
ISPs to put such entries in DNS.

>it would not cause any or irrelevant amount of reduction in spam?
Not that I recall.  These protocols only become 'mandatory' if they 
catch on and become broadly used. The IETF has no power to force people 
to follow their rules.
MTAmark has less of a chance to catch on than LMTP, because it provides 
a smaller incentive to adoption, as I've explained in a previous post.  
If your domain is being forged, you're highly likely to adopt LMTP.  If 
a ISP's IPs are being used to spam, they may well not adopt MTAmark.  
I'm not against MTAmark; I think LMTP should be a higher priority.

>it to the dns and everybody should be happy.
Should, should....  The ones that will are the ones that terminate their 
spamming customers.  I don't see MTAmark providing any incentive for 
ISPs to be more responsible than they are now. 

>easy to develop support for it. If there are no major problems with
I think Eric Raymond explained why a try everything and see what sticks 
plan isn't ideal.  It dilutes resources.

PHB: You contribute valuably, but please stop repeatedly whining OT 
about DNSSEC WG's 'bad' practices when your company's ongoing 
wrongdoings (which folks don't whine about here) are so egregious, and 
your proposals often promote Verisign's (patented, proprietary, contrary 
to IETF policy) technology.  Not to mention that certs don't cost $350 
as you claimed, if bought from Verisign competitors who charge much less.

---

From: "Tomi Panula-Ontto" <[email-masked]>
Date: Tue, 9 Dec 2003 12:58:20 +0200

On 12/09/2003 6:45 PM, Matthew Elvey said:

----- Original Message ----- 
From: "Matthew Elvey" <[email-masked]>
To: "Tomi Panula-Ontto" <[email-masked]>
Sent: Saturday, December 06, 2003 6:45 PM
Subject: Re: [Asrg] Re: 6. Proposals: MTA MARK

[cut]
> ISPs to put such entries in DNS.

If that's the case,  I suggest you change to more responsible ISP.
I don't think we are doing very good work, if we just leave the
ISPs out. ["They are bad people anyway and yeah, they let their
customers spam all day long" - not in my experience]

IMHO, people using dynamic IPs should not be allowed to run
(trusted) smtp servers anyway. Why so? According to some recent
studies one third of the spam is generated in some compromised
home computers [Exact wording may differ].
People behind dynamic IPs should either use some SMTP AUTH
relay service (like www.asmtp.com) or use the mail server provided
by their ISP. They should not be allowed to take direct contact to
any SMTP server in the world. But hey, that's me, you don't have
to agree.

> catch on and become broadly used. The IETF has no power to force people

I'm aware of that. IETF is here to public and open discussions of the
means (protocols, etc) to do the job.

IETF is just one step. Discuss and design the protocol.
Other people will implement it (if they feel it's worth implementing).
Other people will use it (if it's worth using).

> a ISPs IPs are being used to spam, they may well not adopt MTAmark.

Let's just clear out one thing. When you say LMTP, do you actually mean
LMAP?
(http://asrg.kavi.com/apps/group_public/download.php/15/draft-irtf-asrg-lmap
-discussion-00.txt)

LMAP is based on two concepts: publication of policy by a domain, and
application of that policy by a recipient MTA.

I fear that LMAP doesn't address the problem. Why so?
Who can prevent spammers from stealing credit cards and
registering thousands of domains to use in their spamming
business?

See LMAP discussion paper [5.1.4]

"
Spammers may bypass this scheme through a number of methods, such as:
- Claiming association with a domain not implementing LMAP
- Claiming association with a domain implementing LMAP, but
which has a policy stating anyone can claim such association.
- "Hijacking" systems or MTAs within a domain to send spam.
- DNS poisoning, to force particular LMAP information on an MTA
- Registering domains, and implement LMAP.

Recipients can use methods other than LMAP to defend against such
attacks.  These methods may include whitelists, blacklists, greylists
[ref], and content filtering.  There is no requirement that LMAP be
the only source of information for implementing site policy.
"

ReverseMX or MTAMark are simply distributed whitelists
managed by the network owners (ISPs). Even though I think
in my humble mind that ISPs should be forced to adopt
such policy, there is no way to do that, until the protocol
is well functioning and easily adoptable by the organizations.

If we ever finish the "protocol" and get working implementations,
then maybe we can get some acceptance and perhaps even
widespread usage to it.

If we ever reach that point, then it's time to start discussions with
IANA, RIPE, ARIN, APNIC, etc. to enforce the rule.

> ISPs to be more responsible than they are now.

Well, if that's the case then I'm sure the ISPs are happy to sell
their massmailers err.. MTAs for spammers.

> plan isn't ideal.  It dilutes resources.

So we should go and try LMAP and see them exploit it in
matter of days, right?

And whos resources?

I don't know how spammers operate, but they really seem quite
professional at it, since whenever I have added a new RBL
sources to my blacklisting MTA the amount of spam is reduced
only for few days or perhaps weeks. Pretty soon, they are able
to reroute whole damn thing and we are back on the same level
we started from.

And they are doing the very same thing in message headers,
the message itself. They are trying to keep ahead of the spam
prevention and they're really doing pretty good job there.
They get their living out of it.

Do you really think they would not do it for LMAP? Or any
other means? Of course they will. As long as they can.
If there are easy, and relatively cheap ways to circumvent
a problem, then they'll do it.

---

From: "Alan DeKok" <[email-masked]>
Date: Tue, 09 Dec 2003 13:10:28 -0500

> application of that policy by a recipient MTA.

  Exactly.

> registering thousands of domains to use in their spamming

  Law enforcement.  Theft of credit cards isn't an issue we can solve
in the network.

  Right now, much of spammers behaviour is already illegal.  LMAP
makes it more likely for them to engage in more illegal behaviour.
This makes them easier to catch, and gives law enforcement more
inducement to catch them.

  It also gives registrars more inducement to do sanity checking on
registration, if large percentages of registrations are found to be
fraudulent & criminal.

  Alan DeKok.

---

From: Yakov Shafranovich <[email-masked]>
Date: Tue, 09 Dec 2003 14:56:38 -0500

[..]
> registration, if large percentages of registrations are found to be

LMAP is only one piece of the puzzle, its intent is to reduce some forms 
of forgery and give greater traceability. With LMAP it is much easier to 
trace a spammer to a specific domain, and from that point on trace the 
money trail used to register that domain.

Yakov
-------
Yakov Shafranovich / asrg <at> shaftek.org
SolidMatrix Technologies, Inc. / research <at> solidmatrix.com
"All that is gold does not glitter" (LOTR)
-------

---

From: "Hector Santos" <[email-masked]>
Date: Tue, 9 Dec 2003 14:03:07 -0500

> registration, if large percentages of registrations are found to be

Question,  I have not seen the CAN-SPAM bill (any one with a link to it? I
can't seen to find it)

Nonetheless, from what I know of it, spammers are only required to provide a
valid return address.

How will LMAP address this CAN-SPAM legal requirement?

I like LMAP, I already have begun implementing the LMAP-based design as
options for admins.

However, maybe I'm wrong, but it doesn't seem to go far enough if CAN-SPAM
is to be followed.

Remember, as a developer,  I need to be able to provide the functionality to
the admins.  We are going to be bombarded by the "layman" admins who will be
asked by their boss because he heard of the new buzz word,   CAN-SPAM,  if
their mail system supports it.

In short, is LMAP CAN-SPAM Ready?

- Hector

---

From: Yakov Shafranovich <[email-masked]>
Date: Tue, 09 Dec 2003 15:03:44 -0500

Tomi Panula-Ontto wrote:
[..]
> a problem, then they'll do it.

If spam can be looked at as a disease than RBLs are treating the 
symptoms by listing IPs that are likely to abuse the network. LMAP, MTA 
MARK and related proposals are more geared towards treating the causes 
of the disease by addressing some of the architechtural issues on the 
Internet that allow spam to proliferate. For example, spammers are free 
to forge the MAIL FROM address with any domain in place. LMAP addresses 
this forgery issue forcing spammers to use their own domains. MTA MARK 
addresses the issue of hijacked computers being used for sending spam.

All of these simply reduce the freedom that spammers currently have to 
do their deeds. With that freedom reduced spammers will be left with 
less methods to be used, all of which would allow greater traceability. 
Combined with proper law enforcement, cooperating ISPs, and registrars, 
this can help reduce the problem by tracing spam to the real world.

Yakov

-------
Yakov Shafranovich / asrg <at> shaftek.org
SolidMatrix Technologies, Inc. / research <at> solidmatrix.com
"Be liberal in what you accept, and conservative in what you send" (Jon 
Postel)
-------

---

From: "Hector Santos" <[email-masked]>
Date: Tue, 9 Dec 2003 16:04:46 -0500

Yakov, Alan,

I need some input here.

Ok,  Now that I am sold on LMAP or implementing a LMAP-based solution in our
software, I have to see how best this is:

1) Introduced and offered to our customers,
2) Setup or configured to automate the support process.

Keep in mind the following: A) Wildcat is 100% GUI configuration, hence the
majority of our customers expect anything new to be easy to setup and
implement using a GUI setup.  We also do this to minimize our support
overhead, and B) I am not a DNS administrator. So when it comes to
"records", I have limited knowledge on setup.

So tell me, what do I need to add to our SMTP Server Setup dialogs?

I'm thinking that they need to "Help" in defining their MX and TXT LMAP
records?

So in our Anti-Spam Property Sheet, it could be something like:

This is for per-domain.

   Domain: XXXXXXX.COM

   [ Anti-Spam Controls ]

   [X]  Enable RBL                             [ Settings...]
   [X]  Enable LMAP                            [ Settings...]
   [X]  Enable HELO/EHLO Controls              [ Settings...]
   [X]  Enable MAIL FROM  Controls (WCSAP)     [ Settings...]
   [X]  Enable RCPT TO Controls                [ Settings...]
   [X]  Enable DATA Controls                   [ Settings...]

   [OK] [Cancel] [Help]

For LMAP control settings:

   [ Ant-Spam-LMAP Controls ]

   [X] Enable or
   [_] Enable LMAP-based XXXX
   [X] Enable LMAP-based YYYY
   [_] Enable LMAP-based ZZZZ

   ????

   LMAP TXT RECORD: _______________________  [ Save to DNS ]

I read the various proposals

So if you assist with what needs to be done in the LMAP settings, this will
help me getting a basic understanding on helping our customers get deploed
quickly.
Thanks

--- Hector

---

From: Philip Miller <[email-masked]>
Date: Tue, 09 Dec 2003 17:38:49 -0500

> In short, is LMAP CAN-SPAM Ready?

In short, LMAP has nothing to do with CAN-SPAM. CAN-SPAM has various
requirements. LMAP would be a good thing regardless of any legislative
approach, because it allows perfect enforcement of a domain's stated policy
without legal support. Perhaps it could boost the efficacy of CAN-SPAM, but 
it doesn't address that in any way, nor should it.

Philip Miller

---

From: "Hector Santos" <[email-masked]>
Date: Tue, 9 Dec 2003 18:55:57 -0500

Ok, that's the theory.

In practice, developers who will have the ultimate decision to implement or
more suite of proposals, will also need to also consider the marketing
pressure to support what will be the law.  That will be a fact.

If proposal Y covers CAN-SPAM, it will be used over Proposal X which does
not.

Of course, it should be obvious that a proposal that covers CAN-SPAM return
address requirements will also include the proposal (or similar concepts)
that only works at the lower level.

The potential problem I see with any proposal that does not support CAN-SPAM
requirements is that it opens the legal door for CAN-SPAM compliant spammers
to legally sue those systems that are rejecting mail using non-CAN-SPAM
methods.

Again, I have not read the CAN-SPAM bill yet, but I believe I also read
(here) that the bill stated mail systems must be IETF compliant.  No?

If so, that's good, because that means that LMAP is CAN-SPAM ready once the
IETF adds LMAP as a STD specification, not RFC specification.

Remember, CAN-SPAM is a double edge, it places controls and restrictions but
it also gives spammers the legal authority to send spam and if a mail system
is rejecting/filtering mail using non-CAN-SPAM methodologies, it can
potentially opens Pandora's box.

So in short, the answer is LMAP will be "CAN-SPAM Ready" once it is made a
IETF standard.  If it doesn't become a standard, developers, such as myself,
will use need to consider something else that is .   That's the bottom line.

It does look like LMAP has the blessing of many here and will become a
official IETF standard.  So I don't see a problem.

Thanks for your input Phillip.

-- Hector

---

From: Markus Stumpf <[email-masked]>
Date: Wed, 10 Dec 2003 01:12:46 +0100

> potentially opens Pandora's box.

Please remember that CAN-SPAM (as a law) is totally irrelevant to most of
the world.

    \Maex

-- 
SpaceNet AG            | Joseph-Dollinger-Bogen 14 | Fon: +49 (89) 32356-0
Research & Development |       D-80807 Muenchen    | Fax: +49 (89) 32356-299
"The security, stability and reliability of a computer system is reciprocally
 proportional to the amount of vacuity between the ears of the admin"

---

From: "Hector Santos" <[email-masked]>
Date: Tue, 9 Dec 2003 19:35:00 -0500

----- Original Message ----- 
From: "Markus Stumpf" <[email-masked]>
To: "Hector Santos" <[email-masked]>
Cc: "Philip Miller" <[email-masked]>; <[email-masked]>
Sent: Tuesday, December 09, 2003 7:12 PM
Subject: Re: [Asrg] Re: 6. Proposals: MTA MARK

> Please remember that CAN-SPAM (as a law) is totally irrelevant to most of

That goes without saying.

But that does not mean foreign mail coming into the US can not be subject to
legal restrictive access.   It just means a foreign non-compliant sytem
would not (or more difficult) to be subject to penalties or charged with a
crime.  By the same token, it may be that a foreign compliant system have
less or no rights to sue anyone in the states for blocking mail using
non-compliant methods. :-)

-- Hector

---

From: Bart Schaefer <[email-masked]>
Date: Wed, 10 Dec 2003 07:07:01 +0000

I am not a lawyer, but as it happens, I _have_ read the CAN-SPAM bill.
You can look at it here:

    http://www.spamlaws.com/federal/108s877.html

On Dec 9,  6:55pm, Hector Santos wrote:
}
} If proposal Y covers CAN-SPAM, it will be used over Proposal X which
} does not.

It doesn't really make sense to discuss technical changes to MUAs or MTAs
in the context of CAN-SPAM Act "return address requirements."  The main
thrust of the Act prohibits senders from using false or misleading header
information.  A secondary provision is that unsolicted commercial messages
must have a working opt-out mechanism -- which includes "other Internet-
based" mechanisms, as well as the return address.

In other words, the Act does NOT require the return address to be valid
as long as there's some other obvious way to ask the sender to stop.
There's even an explicit provision saying that temporary failure of the
reply mechanism is not considered a violation of the Act.

And the requirements have absolutely no bearing on any message that does
not fall within the Act's definition of "commercial."

} The potential problem I see with any proposal that does not support
} CAN-SPAM requirements is that it opens the legal door for CAN-SPAM
} compliant spammers to legally sue those systems that are rejecting
} mail using non-CAN-SPAM methods.

Baseless FUD.  Secion 8 of the Act:

>        * (c) NO EFFECT ON POLICIES OF PROVIDERS OF INTERNET ACCESS
>          SERVICE- Nothing in this Act shall be construed to have any
>          effect on the lawfulness or unlawfulness, under any other
>          provision of law, of the adoption, implementation, or
>          enforcement by a provider of Internet access service of a
>          policy of declining to transmit, route, relay, handle, or store
>          certain types of electronic mail messages.

} Again, I have not read the CAN-SPAM bill yet, but I believe I also
} read (here) that the bill stated mail systems must be IETF compliant.
} No?

No.  Here's the actual language ("The Commission" is the FTC):

>        * The Commission shall transmit to the Senate Committee on
>          Commerce, Science, and Transportation and the House of
>          Representatives Committee on Energy and Commerce--
[...]
>             * (2) a report, within 18 months after the date of enactment
>               of this Act, that sets forth a plan for requiring
>               commercial electronic mail to be identifiable from its
>               subject line, by means of compliance with Internet
>               Engineering Task Force Standards, the use of the
>               characters `ADV' in the subject line, or other comparable
>               identifier, or an explanation of any concerns the
>               Commission has that cause the Commission to recommend
>               against the plan. *

That's the ONLY reference to the IETF in the Act.  It places requirements
on the FTC report, not on mail systems.
 
} Remember, CAN-SPAM is a double edge, it places controls and
} restrictions but it also gives spammers the legal authority to
} send spam and if a mail system is rejecting/filtering mail using
} non-CAN-SPAM methodologies, it can potentially opens Pandora's box.

Again, I think you're speaking based on a misconception.  CAN-SPAM may
have several edges, but this is not one of them.

---

From: Fridrik Skulason <[email-masked]>
Date: Wed, 10 Dec 2003 09:21:31 +0000

> Please remember that CAN-SPAM (as a law) is totally irrelevant to most of

Unfortunately that's not quite the case.  The law may make it more difficult for
people outside the US to stop spammers operating from the US.  There are also
potential problems for non-US suppliers of anti-spam software and solutions,
trying to sell their software in the US.

-- 
Fridrik Skulason   Frisk Software International   phone: +354-540-7400
Author of F-PROT   E-mail: [email-masked]       fax:   +354-540-7401

---

From: "Tomi Panula-Ontto" <[email-masked]>
Date: Wed, 10 Dec 2003 14:14:29 +0200

Alan DeKok wrote:
----- Original Message ----- 
From: "Alan DeKok" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, December 09, 2003 8:10 PM
Subject: Re: [Asrg] Re: 6. Proposals: MTA MARK

>   Law enforcement.  Theft of credit cards isn't an issue we can solve

Yes.. but spam generated from these domains is something we
can solve. What I mean is: Domains are simple and easy to register.
In simply few hours one is able to register a domain and setup
it for spamming. Networks are different thing. It isn't that easy
to register a C-block for your company and set it up.
We need to secure the network [to protect ourselves and others],
not just domains.

> inducement to catch them.

In the detailed story of compromised server [link posted by Jon Kyme], there
are couple of countries ilvolved. At least Russia, Germany and Portugal are
mentioned.
(Here is the link http://www.securityfocus.com/guest/24043)

Not knowing in which country the spammer actually operates,
it'll be damn hard job for the law enforcement to catch up with
these guys. And it usually requires that the company, whose computers
are compromised, must make report of an offence. Usually [in my
experience] companies don't want bad publicity. Their reputation is
at stake. So, if companies don't want to make it official, how can
the law enforcement ever catch up with them?

> registration, if large percentages of registrations are found to be

Theft of credit cards is just an example. They can as well buy the
domains legally. It really depends how much money they are making.

Tomi

---

From: "Tomi Panula-Ontto" <[email-masked]>
Date: Wed, 10 Dec 2003 14:51:11 +0200

Yakov Shafranovich wrote:
----- Original Message ----- 
From: "Yakov Shafranovich" <[email-masked]>
To: "Tomi Panula-Ontto" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, December 09, 2003 10:03 PM
Subject: Re: [Asrg] Re: 6. Proposals: MTA MARK

> addresses the issue of hijacked computers being used for sending spam.

True, but actually, MTAMark and ReverseMX don't address the issue of
hijacked computers completely. It merely changes the situation so that
the hijacked computer will not take direct connections to the receiving
MTAs,
but instead spammers must try
a) to make the hijacked computers send messages via registered MTA for that
network
b) hijack the dns server (to register that hijacked computer)
c) hijack the registered MTA
d) any ideas?

Anyway, it'll limit their possibilities and will target their efforts
on compromising the MTAs, workstations and DNS servers.

> this can help reduce the problem by tracing spam to the real world.

One interesting point.. since spammers are knowledgeable and follow
their time - they are propably reading this list, too. Either archived
version
or the subscribed one. I wonder if any of the subscribers or IP addresses
in the list archive weblog can be tracked to spammers...

I don't mean to offend anyone, I just wonder what kind of security
additions they would suggest.

---

From: Fridrik Skulason <[email-masked]>
Date: Wed, 10 Dec 2003 17:25:00 +0000

---

From: David Maxwell <[email-masked]>
Date: Wed, 10 Dec 2003 14:16:34 -0500

> on compromising the MTAs, workstations and DNS servers.

The key is:

MUA running machines are maintained by end-users.
MTA/DNS running machines are maintained by network administrators.

The MTA/DNS machines are likely to be orders of magnitude more safe from
attacks, due to correct configuration, choice of OS, up to date patch
sets...

-- 
David Maxwell, [email-masked][email-masked] -->
Net Musing #5: Redundancy in a network doesn't mean two of everything and
half the staff to run it.
					      - Tomas T. Peiser, CET

---

From: Yakov Shafranovich <[email-masked]>
Date: Wed, 10 Dec 2003 17:32:37 -0500

> attacks, due to correct configuration, choice of OS, up to date patch

There are also things like rate limiting which can help with the ISP's 
MTA. As for DNS threats, if the DNS system begins to get attacked, this 
will provide an incentive towards securing it (via DNSSEC, or some other 
way). Threats to DNS is not really within our scope, and is being 
handled by one of the DNS WGs.

But you are correct in stating that spammers will seek other means, and 
their unholy alliance with virus/worm writers, as well as hackers, will 
definatly increase in size. This is something that general network 
security folks have to worry about, and is out of the scope for this.

Nevertheless, this issue should be mentioned in some document, so we are 
aware of it, but it is not a reason against implementing something.

Yakov

-------
Yakov Shafranovich / asrg <at> shaftek.org
SolidMatrix Technologies, Inc. / research <at> solidmatrix.com
"They that can give up essential liberty to obtain a little temporary 
safety deserve neither liberty nor safety" (Benjamin Franklin)
-------

---

From: Mark <[email-masked]>
Date: Wed, 10 Dec 2003 23:08:37 GMT

----- Original Message ----- 
From: "Tomi Panula-Ontto" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, December 09, 2003 11:59 AM
Subject: Re: [Asrg] Re: 6. Proposals: MTA MARK

> home computers

If that logic holds true, then there is exactly a twice more compelling
reason to disallow static IP addresses from running trusted SMTP servers. :)

- Mark

---

From: Yakov Shafranovich <[email-masked]>
Date: Wed, 10 Dec 2003 18:12:21 -0500

> reason to disallow static IP addresses from running trusted SMTP servers. :)

Humor aside, those studies may not be accurate. A while back a report 
from MessageLabs claimed that over 80% of all spam was sent from 
hijacked computers. When asked directly, MessageLabs admitted that they 
were counting open proxies as "hijacked computers". So anytime such 
study is made, you have to check the raw data.

Also, I emailed Sophos who made the original study to obtain the raw data.

Yakov
-------
Yakov Shafranovich / asrg <at> shaftek.org
SolidMatrix Technologies, Inc. / research <at> solidmatrix.com
"Some lies are easier to believe than the truth" (Dune)
-------

---

From: "B. Johannessen" <[email-masked]>
Date: Thu, 11 Dec 2003 00:21:50 +0000

> study is made, you have to check the raw data.

For what it's worth, here are some information about the senders of 
spam that ended up in my traps Tuesday (midnight to midnight UTC):

Spam seen: 246
Distinct IPs: 231
IPs in dul.dnsbl.sorbs.net: 121
IPs running unfiltered "Microsoft Windows msrpc": 111
IPs running unfiltered "Microsoft Windows UPnP": 86

This in itself proves nothing, but I don't think it would be
unreasonable to assume that a significant portion of the 121
machines listed in dul.dnsbl.sorbs.net have been compromised.

If numbers like these are of any interest, I'll post some more
detailed numbers when I have more data, and some time to do a
more in-depth analysis.

	Bob

-- 
--=[ B. Johannessen | [email-masked] | http://db.org/ | +4797152009 ]=--
----=[ uptime: 2 days, 5:55 | load: 0.10 | inbox: 4 messages ]=-----
------=[xmms: Police - Every Little Thing She Does Is Magic]=-------

---

From: Yakov Shafranovich <[email-masked]>
Date: Wed, 10 Dec 2003 21:53:00 -0500

> detailed numbers when I have more data, and some time to do a

I think that the Analysis subgroup might be very happy to look at this 
stuff. I have CCed the coordinator of that subgroup on this message.

Yakov
-------
Yakov Shafranovich / asrg <at> shaftek.org
SolidMatrix Technologies, Inc. / research <at> solidmatrix.com
"And this too shall come to pass"
-------

---

From: Fridrik Skulason <[email-masked]>
Date: Thu, 11 Dec 2003 09:22:01 +0000

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.F@mm.  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?

---

From: "Tomi Panula-Ontto" <[email-masked]>
Date: Thu, 11 Dec 2003 12:26:00 +0200

Mark wrote:
----- Original Message ----- 
From: "Mark" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, December 11, 2003 1:08 AM
Subject: Re: [Asrg] Re: 6. Proposals: MTA MARK

> reason to disallow static IP addresses from running trusted SMTP servers.
:)

True :-)

On the other hand - if I terminated smtp connections from
machines that are behind dynamic IPs, I would propably not lose
any valuable email.. but if I terminated connections from static IPs,
I would propably lose all of my important emails and get only spam.

Tomi

---

From: Philip Miller <[email-masked]>
Date: Thu, 11 Dec 2003 12:50:45 -0500

Fridrik Skulason wrote:
> [snipped discussion of worms]

This is exactly why the group is reviewing it. Keep it up.

> (which, by the way seems to be mis-spelled as LAMP in one or two places

The misspellings occur in:
4.1.10 Requirement 2.10, Single Solution
4.1.11 Requirement 2.11, Technical Rather Than Legislative

>    "No LMAP data available."

Those are correct.

> cases - or if it can indeed do so.  Clarification, anyone?

There is no need or reason to distinguish, unless you want to talk about 
informing the sender that their machines are trying to send unauthorized 
mail. That's orthogonal to the protocol's narrowly defined goal of 
preventing domain forgery.
If someone wants to report such abuse, they are quite able to look up the IP 
in {ARIN, RIPE, etc} and find the appropriate address to send that message to.

Philip Miller

---

From: Markus Stumpf <[email-masked]>
Date: Fri, 12 Dec 2003 00:51:55 +0100

> by the anti-virus community.

I don't know if I am a "k00l VXdudez", but I had 5 years of Latin in
school and the correct plural of "virus" is "viri" (not "viruses" and
in no way "virii" ;-). The plural form was very rarely used in written
text, so some people say is doesn't have one in Latin, which is wrong.

However, according to the Oxford English Dictionary, the correct plural
in English language is "viruses". I'll change that. Please blame it to
the fact that I am not a native English speaker ;-)

> through the ISP of the end user.

This is not true.
Even very "simple" viruses like VBS/Lovelet-AS spread via eMail by using
the MAPI of the infected host. It did NOT have its own SMTP code. Some
of the recent viruses do have their own SMTP module talking SMTP directly
to remote hosts, some of them simply use e.g. the MAPI of the infected
host. Whether the message that is sent via the MAPI uses smarthosts or
gets delivered directly depends on the global configuration of the MAPI.

The mention of CodeRed and Nimda is in a section that argues
that one cannot trust on users to update their computers, even if the
security holes are some month old and patches exist for quite some time,
just like you can't count on them to configure their programs correctly 
as can be seen from the number of open proxy servers.

> ASDL or broadband connection.

We don't have an AV software in that mailserver, but we reject
executable attachments based on base64 signatures. The rejections of
the last 7 days are at
   http://www.space.net/~maex/asrg-exec.txt
First row is the number of rejections, second row is host:ip. With a
probability of nearly one, all of the filtered messages have been
viruses. Apart from the data you collected from the Sobig.F outbreak the
spreading with the average background noise shows a little different data
according to the above numbers.

> This is what one would have expected

I don't think so. IMHO spammers don't care too much, speed is a nice to
have addon but I don't think it makes a big difference for them if the
compromised host takes 2 or 5 hours to blast out the spam.

> cases - or if it can indeed do so.  Clarification, anyone?

LMAP can't distinguish and it is IMHO irrelevant. The machine is not
authorized to send emails with a sender address from domain example.com,
regardless under whom's authority the machine is.

	\Maex

---

From: "Chris" <[email-masked]>
Date: Fri, 12 Dec 2003 13:28:23 +1030

an interesting note about the plural of virus

Taken from...
http://www.cs.helsinki.fi/linux/linux-kernel/2001-30/0607.html

What I don't understand is why people use the form virii, with a double I!

Just like the plural of abacus is abaci, the plural of cactus is cacti
(check the dictionary if you don't believe me), shouldn't the plural of
virus be viri, with one I at the end (of course, "viruses" is also currently
accepted as a plural, and even preferred by some people).

I think people get confused by the fact that the plural of radius is radii.
That extra "I" comes from the i in radius - it shouldn't appear in the
plural
of "virus"! The plural of the different word "virius" should have been
virii.
===============================

I was always told virii was the plural and 'viruses' was vulgar

well I'll use viri from now on

Regards
Chris

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Markus Stumpf
> Sent: Friday, December 12, 2003 10:22 AM
> To: Fridrik Skulason
> Cc: [email-masked]

---

From: Fridrik Skulason <[email-masked]>
Date: Fri, 12 Dec 2003 11:13:07 +0000

Perhaps I need to clarify...see below:

> Even very "simple" viruses like VBS/Lovelet-AS spread via eMail

It is a worm.  The definition of a "worm" is basically "self-replicating
software that spreads over a network".  There is some disagreement on 
the formal definition of "virus" - one group of AV people considers all
intentionally self-replicating programs to be  "viruses", and worms 
therefore just a specific subset of "viruses".  Other researchers 
consider worms and viruses to be different, partially overlapping
subsets within the category of self-replicationg programs - arguing that
the definition of a virus relies on the infection process, while the
definition of "worm" relies on the distribution process and those are
somewhat independent.

In any case, any self-replicating program that sends itself by mail
(regardless of whether it uses its own SMTP engine or not is a worm.
Some of those are also viruses - in other cases there is an ongoing debate 
on whether to consider them viruses or not.  As the proposal would only
affect worms, not viruses that are not worms as well, I am just suggesting
that it would make more sense to talk just about worms to reduce the 
confusion.

Some worms would simply not be affected by MTA MARK at all, namely those
that send mail just as if a "real user" was actually sitting at the keyboard
and pressing the keys.  There is just no way for a a protocol of this kind
to distinguish between a worm of this kind and a legitimate user sending
mail.  Worms of this category do not have their own SMTP code - which is
really what I meant earlier - sorry if this was not clear enough.

> as can be seen from the number of open proxy servers.

All I was saying is that CodeRed is a bad example, as someone might 
incorrectly assume that MTA MARK would have been effective against it.

> regardless under whom's authority the machine is.

This is not relevant to MTA MARK, of course, but the issue is not
irrelevant, as the appropriate reaction would be different.  In the 
first case the the owners of the domain in question would hopefully
want to track down the compromised machine and take care of the
problem.

In the second case, the owners of the domain would only be interested 
in tracking down the machine if they were planning to go after the
person responsibel for well..."fraud".

I just brought this up because it seemed useful if LMAP would be able to
distinguish between those two cases.

---

From: Philip Miller <[email-masked]>
Date: Fri, 12 Dec 2003 07:57:54 -0500

Fridrik Skulason wrote:
> [snipped  worm discussion]

I have to cast my vote on the side of using 'worm' instead of virus. 
This is a community of professionals, who've volunteered to contribute 
their time and knowledge, and I think it's pretty clear Fridrik should 
know what he's talking about.

> incorrectly assume that MTA MARK would have been effective against it.

It's easy enough to just say "Users cannot be trusted to keep their 
machines secure and up to date." If there's anyone in the IETF 
commmunity who doesn't believe that, they probably haven't been exposed 
to users recently (within the past 9 or so years).

> distinguish between those two cases.

The appropriate reaction on the part of the recipient MTA (remember, 
there is no human involvement in the mail transport system after 
origination) is to reject the message with a PERMFAIL code. If LMAP 
catches on, the incidence of attempted domain fraud will drop because it 
will be clearly seen as futile. There's no reason to bother the domain 
owner to let them know that someone's committing fraud, the domain owner 
implemented LMAP so they would never have to hear about it. Similarly, 
if you were receiving clearly unauthorized or abusive traffic from a 
specific address, regardless of SMTP or otherwise, you would report it 
to the owner of the address range, just as it sometimes happens now. The 
address owner could coincide with the owner of the claimed domain, but 
that doesn't matter.

If Alan DeKok hasn't been following this, one of us may want to bring it 
to his attention. Considering that this point did spark some debate, 
verbiage might be necessary in the draft documenting this decision.

Philip Miller