On Fri, Dec 12, 2003 at 05:07:19PM -0500, Alan DeKok wrote:
Markus Stumpf <maex-lists-spam-ietf-asrg(_at_)Space(_dot_)Net> wrote:
But with the presumption of innocence each one should be allowed to send
a mail to another person on the internet without some authority blocking
it by default "just because".
My whole point is that you may have *reasons* for blocking port 25:
The user didn't accept responsibility for traffic being sent to that
port, coming from his network.
Our customers are responsible for the traffic they generate. Who says
they aren't? And customers that abuse our AUP or have 0wned hosts not
only get port 25 blocked but they get pulled the plug.
Similarly, you probably block BGP connections from people you don't
have peering agreements with. I don't see how blocking any other
protocol is different.
Where's the problem?
/You/ (and that's the analogy here) are free to block all connections to
/your/ SMTP port and only allow a whitelist through.
Are you running a webserver?
Should we also block all outgoing connections on port 80, because some
customers could access your server just for fun and retrieve some
documents without reading them just to generate traffic that you have to
Btw. Referers are used for spamming already. As nearly all webserver
operators are horny for access statistics and from where their site is
linked from spammers retrieve homepages and send faked referers to make
the operator visit this page and be loaded by spam and ads.
Oh, and ping packets, we have to block ping packets.
Reading and controlling each and every email before letting
it pass the border of your IT infrastructure is impossible for anyone/
any business with more than 100 emails a day and 5 people. Even more if
you have to take care about data protection.
Again, I have NEVER said that doing this would be a good idea. I
don't see why you're bringing it up. It simply isn't relevant.
Sure you said:
*> I understand how that's nice, in an ideal world. The problem is
*> you're confusing "censorship" with "quality control". You're
*> confusing "censorship" with "self-protection". Your freedom to swing
*> your fist ends where my face begins. It's not a difficult concept.
How would you accomplish "quality CONTROL"?
And if I swing my fists and you move your face forward, is that my fault?
We have an AUP that forbids to send "bad" mails (whatever that means, in
our case it's including UCE and spam) and we can take actions if a customer
fails to adhere. But unless he fails, he has free and unfiltered access to
the Internet and IMHO this is a good thing.
The point I was trying to make is simple: I don't understand why
you're treating SMTP different on one hand (you have an AUP), but then
claiming you're not treating it differently on the other (you claim to
give free and un-filtered access to the net.)
I don't get your point.
Is a free country "unfree" because they have laws?
Our AUP covers als hacking and other abusive behaviour. So we're not
treating SMTP different, but we're making differences in behaviour.
You've already decided that you have NOT given your customers
absolutely free and totally unfiltered access to the net, so stop
trying to pretend otherwise. You're already filtering network traffic
you find abusive, or which attacks your local infrastructure.
No we don't as long as it doesn't happen.
As long as a customer is not abusive he is free to do whatever he likes.
And just as I don't knock down everyone I meet because he could
potentially try to rob a bank we don't block customers unless they
It makes sense to me, then, if we both agree to each filter network
traffic which abuses the other person. It just saves time, money, and
work for everyone.
If we get a complaint we analyze it, and if there is evident of abuse
we do not filter the customer, we pull the plug and terminate the contract.
No, they can't.
Our routers do know which side the addresses may come from.
So you're doing even more filtering than you said originally. Why
not extend that filtering to network abuse *other* than forged
No, that's abusive packets /not/ originating at our customers, if they
are from the outside. If they are from the inside they are abusive
per definition and the inspection can be done automatically. We will be
notified and machine will be null routed.
I cannot automatically test all emails of all customers whether they are
abusive or not.
My point is that "free and unfiltered access to the net" does not
exist for the vast majority of people.
And this is an argument for what?
Even "access to the Internet" does not exist for the vast majority of
ISP's are already limiting the things they let customers do.
These ISPs will die.
Things like MTAMark or port 25
filtering, are less than optimal, but they won't result in the
destruction of the Internet, or even the "end to end" principle.
Just a reminder: my co-worker and I are the authors of MTA MARK.
SMTP has never been "end to end".
I have always seconded that and had flame wars with people saying
RFC 2487, Section 7, Security Considerations, says:
It should be noted that SMTP is not an end-to-end mechanism
See? You can filter port 25 without the Internet exploding. The
RFC's say so.
If you quote a RFC you shouldn't mis-quote it. This is unfair to the
authors and distorting.
The section clearly makes a differentiation because there is
MUA <-> MTA <-- smtp --> MTA <-> MUA
MUA <-- smtp --> MUA
and that's why according to that RFC SMTP is not an end-to-end mechanism.
The RFC does not say anything about companies, users or hosts as end-to-end
partners. Is only says that it is not a MUA <> MUA protocol.
And SMTP is without any doubt an end-to-end mechanism for most SMTP servers
and without any doubt a large number of companies and organizations that
are customers of ISPs, run their own SMTP speaking MTA in an end-to-end way.
And that is what you want to abolish.
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"
Asrg mailing list