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. 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.
Second: you are completely misguided in your wish to reject mail after
SMTP data stage. 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. 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. 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.
Kai
--
Get your web at Conactive Internet Services: http://www.conactive.com
