[EMAIL PROTECTED] wrote on 10/06/2005 00:25:35:
> We're all happy to discard viruses without bouncing them.
> We're even OK with the idea of discarding SPAM without notifying the"sender".
> It's not hard to conclude that bouncing in these two cases is utterly wrong,
> despite what the RFCs may say.
> If you accept the above, we've now all accepted that it is OK to discard
> certain types of email without notifying the sender.
I agree, of course, and do the same here. No way to not do it!
> I can't see why it is so much of a mental leap to discard unknown local
> addresses, especially if you can reject them before you've even received the
> message body. Please enlighten me if you disagree.
I don't disagree with such feature, but it is not in default Qmail code.
Qmail to act like this - yes, it is possible - needs patches.
BTW, Qmail needs patches for many many features...
> > Read throughfully into SMTP RFC and you will understand that bouncing is a
> > defined and legitimate feature in all MTAs.
>
> I have no problem with support for bounces in the various RFCs. In the right
> circumstances, bouncing is a legitimate function. I do have a problem with
> *what* can be bounced.
>
> I have a problem with the idea that an MTA knowingly accepts mail that it
> cannot handle. In this day and age, a whole lot of issues could be solved if
> it was to "reject" instead of "accept & bounce".
You can change the way it does that. It's code is open.
You just need to be careful to not provide your modified code to be distributed, instead you have to provide a patch.
> I don't even believe this is a problem with the existing RFCs. If you
> examine/modify the interpretation over what mail you *must* accept then you
> don't even get to the point where you have to make a decision over bouncing.
>
> > Bouncing now is considered harmful because high amount of spam and garbage
> > being spread over net.
> > Spamcop even blocks servers that provide bounces, legitimate or not.
>
> So it's not just me that has issues with this behaviour :-)
>
> > There
> > has been a large discussion between Spamcop founder and Qmail list that
> > ended up with no solution - it became a religious discussin with Qmail
> > defending RFC statements and Spamcop guy defending its "feature"...
>
> Once upon a time we all lived in caves. If qmail wants to live in the past,
> far be it from me to change the official religion.
It is not the point to live in the past or not.
The point is about the way Qmail was developed, licensed etc etc.
If you want a modern Qmail install, I can provide you some info instead of starting over discussions over what is old is bad.
My install is Qmail based on original code plus:
Erwin Hoffman SPAMCONTROL
SPF feature that I patched myself based on some patch I grabbed in the net
Qmail-Scanner
ClamAV
SpamAssassin
Discard feature that I wrote - similar to Postfix discard feature
SpamGuard - that feeds my discard list based on spam volume I had accepted in the last minute.
RRD graphs to follow (almost real-time) how much spam/virus/bounces/inbound/outbound message volume.
Using receipient checking on smtp session I am able to block over 1,000 messages/min in a customer environment. Right, no bounces!
You can have a rich-feature MTA with Qmail, just grab the patches you need.
Regards.
- Re: [Qmail-scanner-general]INCONTROLED SPAM Pamcho
- Re: [Qmail-scanner-general]INCONTROLED SPAM Jason Haar
- Re: [Qmail-scanner-general]INCONTROLED SPAM Adam Goryachev
- Re: [Qmail-scanner-general]INCONTROLED SPAM hamann . w
- Re: [Qmail-scanner-general]INCONTROLED SPAM Adam Goryachev
- Re: [Qmail-scanner-general]INCONTROLED S... Jeremy Bowen
- Re: [Qmail-scanner-general]INCONTRO... Adam Goryachev
- Re: [Qmail-scanner-general]INCO... Jason Haar
- Re: [Qmail-scanner-general]... Aecio F. Neto
- Re: [Qmail-scanner-general]INCONTROLED SPAM Nerijus Baliunas
- Re: [Qmail-scanner-general]INCONTROLED SPAM Aecio F. Neto
- Re: [Qmail-scanner-general]INCONTROLED SPAM hamann . w