On Tue, May 24, 2005 at 05:40:49PM -0400, Bruce Lilly wrote:
As I understand it from a quick skim, there are however some issues:
Thanks for your comments.
1. it speaks of MTAs and mail severs, however an MUA or MSA may also
send mail, and there is at present no way for an SMTP receiver to
determine whether the connected sending client is an MUA, an MSA,
or an MTA.
This is the idea of MTAMARK.
MUAs SHOULD NOT talk to other mailserver on port 25 but use 587 (submission)
instead. MTAMARK allows the administrator to mark IP addresses in the
Domain Name System as "This IP address is assigned to a MTA that is
intended to send messages across the Internet". If a receiver MTA (aka
MX) receives a connection this gives a hint and if no MTA=1 flag is set
it may reject the message if the connection originator cannot SMTP AUTH
or SMTP after POP or whatever. As MSAs are not allowed to accept connections
that are not authenticated MTAMARK is irrelevant for them.
2. it speaks of "unauthorized message transmission", but SMTP has
no authorization mechanism (unlike, say, IMAP, but then IMAP isn't
used for sending (pushing) mail).
Ok. The problem here may be the semantic difference between "authorized" and
"authenticated". I must admit we mixed the two and we will review the draft
with regard to that.
The idea is to treat connections on port 25 (aka MTA <> MTA (pls read on))
as unauthorized unless either
- the sending IP has a MTA=1 flag
- the connection is authenticated (SMTP AUTH, SMTP after POP, LAN
connection, ...)
In todays mail infrastructure most (nearly all) MTA work as combined
MX/MSA servers. If there is a clear separation there is no need for a MX
to talk to a MUA directly. Each MUA usually has a MSA to authorize with
and inject the message to the Internet mail system.
The goal has to be to make port 25 connections MTA<>MTA only (spamware,
viruses, worms and MUAs are no MTAs).
I always see a MSA as the letter box in real life. To get a message
delivered the person (MUA) has to put the letter into the letter box
(MSA). The postal system (MTA) transfers it to the destination where the
postman (MDA) puts it in the mailbox.
Some buildings allow access to the mailboxes of the inhabitants only to
authorized personal of the various postal companies. This solves the
problem of children hired to put advertising sheets in each and every
mailbox and of trespassers using the mailboxes to put in all kind of crap.
6. authentication is fine where there is a prior arrangement,
however one of the fundamental principles of email is that it
permits communications with no prior arrangement.
IMHO it was never a fundamental principle of email that a MUA can
connect to any MX and get a message delivered. In fact, before the
Internet boom, MUAs like "mail" or "elm" couldn't even speak SMTP.
The principle of "no prior arrangement" is still met for MTA<>MTA
connections but we need a way to distinguish them from
MUA/spamware/worm/virus connections.
This is one of the goals of MTAMARK.
What IMHO we all have to recognize is that the Internet of today is not
the Internet of 1995 or even 1990 or earlier. Times are changing and
- like with other growing schemes - some rules must be redefined for
a better collaboration. If one of the changed rules is that MUAs can
no longer connect to any MX they like and masquarade as a MTA I am all
for it.
And, IMHO, your "no prior arrangement" principle isn't a fundamental
principle of email it show only the shortfalls of the system that
ioriginate from a time when there was no need for it.
3. like other IP based schemes, it doesn't play well with DHCP and
NAT.
I have never seen a "legal" mailserver running on a dynamically changing,
DHCP provided IP address before. NATted networks should not be a problem
as the admin usually already configures which hosts are allowed to perfom
which actions, so adding MTA=1 to the NAT gateway is fine. If this can
be abused by internal clients the address will end up in a RBL despite
the MTA=1 flag. Problem solved.
4. While some parts of IP address space might be managed in a way
which is amenable to the approach, other parts have many widely
separated class C ranges under one administrative entity, which
would seem to mean managing each of those ranges separately.
I don't understand what you mean to say.
As an ISP we manage a few hundred /24 for our customers with regard to
reverse DNS. Customers do contact us to get rev DNS names so I don't see
(in fact we don't have) a problem in also adding MTAMARK records for
hosts they like to be sending MTAs.
Is this the problem you wanted to address above? If yes I don't see this
as a problem.
5. I'm not thrilled about the "unmarked" yes->no flag day concept.
Me neither. We're thinking about dropping this completely.
7. Simply publishing information about which IP addresses might source
messages may reveal information of potential use to an attacker
(not mentioned in security considerations).
Connecting a host to the Internet is of potential use to an attacker.
Security through obscurity never worked. We see more than 50 full scans
per day, so the scanners have probably more and better information
about a host or a network than anyone else.
Is there any specific attack you are thinking about?
What really drives me crazy is that the spam problem is omnipresent.
Everyone from the big companies to the end user is frustrated and wants
the problem to be solved.
But it can only be solved with changes from the existing spam prone
architecture to a more controlled system. But with *every* change everyone
from the big companies to the end user is whining that they don't want
to have anything changed.
So without changes they all get what they want: more and more spam.
... and one change alone will NOT solve the problem.
I am running for 20 days now a reporter on one of our mailservers.
It reports to a central database if the sending hosts doesn't pass a few
*simple* tests:
- IPs sending worms/viruses (virus)
- IPs using the IP/name of the receiving system in HELO/EHLO (badhelo)
- IPs using "localhost" HELO/EHLO (badhelo)
- IPs using "localhost.localdomain" HELO/EHLO (badhelo)
- IPs using "example.com" in HELO/EHLO when the RCPT TO is
"joe(_at_)example(_dot_)com"
(helomatchrcpt)
- IPs sending a MAIL FROM: with a domain that has no A/MX record in DNS
(permdns)
- IPs sending "XXXX" or "POST" as the first command in their SMTP
dialogue (unimpl).
On an average day the mailserver makes around 4000-5000 incoming connections
per hour.
The list of unique abusive IP addresses *grows* with a linear factor of
about 350 entries per hour. A graphical representation (snapshot as of
now) is here:
http://www.space.net/~maex/growth_month.png
(adding virus information has been started a few days later)
If you think that no "legal" mailservers (as one might think) end up in
this list you are all wrong. Most of them send/forward/relay "permdns" and
virus messages.
The question that remains is: why?
\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"
