On Mon May 30 2005 16:40, Markus Stumpf wrote:
On Tue, May 24, 2005 at 05:40:49PM -0400, Bruce Lilly wrote:
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.
Exactly which MSA do you believe they should talk to? The ISP which
receives mail for me also operates an SMTP server for sending mail, on
port 25 (nothing on ports 587 or 465). At the moment I can't get to
it (port 25 blocking). The ISP for the network I'm presently connected
to operates a server on port 25. I know of a server which I can get to
which operates on port 587, but it mangles messages so badly that it's
unusable.
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, ...)
I have an MTA on my laptop which will happily use SMTP AUTH with any
MSA or MTA that supports it. I supply the certificates. Do you
suppose that SMTP AUTH presents a difficulty for spammers?
I always see a MSA as the letter box in real life.
Email doesn't work like postal services. There is no central "post
office" concept in email.
What IMHO we all have to recognize is that the Internet of today is not
the Internet of 1995 or even 1990 or earlier.
OK so far...
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 I would be opposed. I have seen too many problems with ISP-operated
MTAs -- knowledgeable users need a way to work around those problems by
sending directly to the recipient domain's MX hosts if necessary.
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,
Define "legal". My laptop (mentioned above) is connected to a dynamic
IP address (AFAIK; it's behind two NAT boxes, so it thinks it has a fixed
RFC 1918 IP address).
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.
So you have to manage a few hundred zone files...
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.
Of course, but one expects security considerations sections to list
known security issues.
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?
If one says 192.0.2.1 is an MTA and 192.0.2.2 is not, then:
1. an attacker looking to exploit a known MTA vulnerability knows to
try 192.0.2.1 and can ignore 192.0.2.2, without scanning
2. an attacker who wishes to exploit a vulnerability in some type of
device that usually does not operate on hardware that has an MTA
(e.g. a line printer using TCP port 515 lpd protocol) can ingore
192.0.2.1 and concentrate efforts on 192.0.2.2 and other IP addresses
which you have conveniently categorized for him
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.
Not necessarily. Filtering does not necessarily involve architectural
changes, for example.
But with *every* change everyone
from the big companies to the end user is whining that they don't want
to have anything changed.
One could trivially solve the spam problem by making all email fail; no
email, no spam. Some schemes come pretty close to that...
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 [...]
The list of unique abusive IP addresses *grows* with a linear factor of
about 350 entries per hour.
And this surprises you? A host connected via DHCP may have a new IP
address every time it connects -- some ISPs assigning IP addresses via
DHCP have timeouts on the order of 1 hour.
That doesn't mean that every machine connected via every IP address that
has ever had a problem always has the same problem, forever. A
Windows-infested virus box (or is it the other way around :-) may have
a particular IP address at one time, using it to spew spam, and a minute
later a legitimate user may be sending legitimate mail from the same IP
address. Or vice versa.
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?
Maybe because you're assuming (consciously or not) that DHCP doesn't exist?