Kai Schaetzl wrote:
Brian wrote on Tue, 09 Mar 2010 06:51:45 +0000:
Yes, but that does not answer my question {and is once more Postfix
biased} AFAIK Postfix is totally unable to reject mail at SMTP time that
Spamassassin decides IS SPAM without the aid of a milter or policy
deamon of some kind.
You have a very simplistic view on how mail transportation works and maybe
on how software works.
First: Postfix is a M Transport A and not a M Rejection A. It's common
practice in software design to have "plugins" do work that the core
package doesn't. For good reasons. We don't want bloatware and we may want
updates on that plugin much more often then we want updates on the MTA.
Kai, I think it is you who has a simplistic view of how mail
transportation works.
Yes it is true that MTA's need to support plugins. But they need to do
it for a different reason - there are ideas that need to be tested out.
Take for example greylisting. The fact is that when greylisting was
first proposed, nobody wanted it in the MTA. It was too new, and people
did not know how it would work out in practice. There were stability
concerns and concerns with how large round-robin mailserver arrays would
handle it.
Thus it was the Right Thing to implement greylisting in a milter when it
was first proposed.
The same thing goes for issuing REJECTs during the data phase of the
SMTP transaction. The same issues and concerns applied.
However, once these techniques were proven out in practice, at that
point CONTINUING to keep them separated in a plugin or milter becomes
a liability. You now have the big concern that since the development
of the MTA and the milter/plugin proceeds separately, you can have
sync problems where you make a chance in the MTA and the plugin breaks.
Sure, the plugin group may correct the problem but that is not a lot
of consolation to the admin who just happens to regenerate or update
his servers during the time that the plugin is broken and a patch is
in process. And what if the plugin author is tired of working on it
and the plugin project - which is providing a valuable service - starts
to languish?
There have been many plugins and milters developed over the years that
have proven out to be, in a word, stupid. That is why it was a good
thing that they were never part of the MTA code. In that case it was
good to keep them separate. But, there's also many plugins that have
proven out to be critical and useful, and the MTA benefits when that
code is folded into the MTA.
The development and user community can get a sense of how these things
can be separated, and what a good separation is. For example it's clear
that spam content-filtering is far to complex to insert into an MTA
that's why it's good to have a separate project, like SA or dspam or
something else. But, simply dropping the SMTP transaction in the middle
of a data phase due to certain conditions being met - perhaps a keyword
in the body of the message, perhaps a slow or failed DNS lookup of the
sender's IP - that is not complex and has proven out over time to
be fine, and really should be part of the MTA for stability reasons.
I
really do not want to update my MTA time and again because it's got a new
policy feature. Postfix has two interfaces for this, milter and policy
daemons. That's more than other MTA's have and gives you just every option
you want to have. It's the only correct way to do this.
No, it's not. There's plenty of "correct" ways to separate new/untested
functionality from the core proven/tested functionality in an MTA. Your
trying to frame an argument of where you want this dividing line based
on the capabilities of existing code, which is stupid. You are NOT
taking an unbiased look at all of the tasks that a modern mailserver
needs to do and trying to make a logical division of those tasks, then
modifying the MTA code to suit the division, which is the right way to
do it. Instead you are taking some structural decisions made in the
design of an MTA years ago and using them to frame your world view of
how e-mail works in the modern world.
It's no wonder your frustrated. Your like the guy with the Model T
trying to argue that highway speed limits should be 35Mph because that's
as fast as a Model T ever was able to go - and the Model T was the
greatest car ever built and every car following it should be just like it.
Second: you are completely misguided in your wish to reject mail after
SMTP data stage.
No, you are completely misguided in your wish to NOT do the only logical
thing to do to handle spam.
I gather you have a biblical tooth-for-tooth approach
here. This is not good guidance. It does not make any sense to process a
complete message and then reject it. If it's not done correctly it even
violates RFCs. Doing that processing at the SMTP stage may be feasible for
home and soho use, but not for ISP use.
Also quite wrong.
Processing a message takes CPU
power and precious SMTP time. Doing that at SMTP stage means you cannot
take in as much mail as you could.
for a given piece of iron. Solution: buy a newer more powerful server.
Son, arguing that you can still process 10K pieces of mail on your
16MB ram 486/66SX may score you points with the geeky girls, but it's
pretty ridiculous for anyone handling a real mailserver.
It also means that the sending MTA
cannot send as much mail as it could. So, only disadvantages for everyone,
and still *no* advantage. There are other reasons not to do this, for
instance legal ones.
The idea is not to "punish" the other side because it sends spam. You do
not only not punish the other side, you punish yourself. The idea behind a
rejection at SMTP stage is twofold: avoid unnecessary processing and avoid
unncessary traffic. None of that is achieved if you take a whole message,
scan it and reject it at SMTP stage. So, what a clever mail system does is
reject as much spam as it possibly can without getting too many FPs by
technical and policy reasons and queue the remaining, say, 10% for full
message inspection. That's the only effective way to deal with this on a
larger scale.
No actually it's absolutely not. It's absolutely the wrong thing.
Spam senders are 1 of 2 systems:
1) Compromised PC's on cable or DSL lines that have mini-SMTP engines
that just hammer as quick as they can.
If these get an error 5xx they abort the send to that particular victim
and go on to the next victim in the list. They won't retry, and it is
stupid to cry tears over the increased CPU this takes on the hijacked
system, it's not even a mailserver. You WANT them to abort and go on
to the next victim because some of these systems are actually address
spam probes that are collecting addresses for their internal victim
lists, and you definitely want them getting a 5xx since it will help to
purge your address from their victim list.
2) Compromised mailservers.
If these get an error 5xx on a spam then they attempt to bounce the
message. If they can't bounce it (since the sending address is forged)
then they mail the bounce to the postmaster which if there's a
responsible admin, that admin will immediately see their server is
compromised and act to take their server offline.
If the admin has set Postmaster to /dev/null or something then the admin
is acting in a reckless and irresponsible manner on the Internet and
their server deserves to melt down. If rejecting during the DATA phase
causes their server to melt down faster, then all the better.
If you accept the spam, then drop it later, your not providing that
server admin with the feedback they need to know that their server is
compromised, and your rewarding the server admins who have chosen to
act in a reckless manner.
Ted
