On Fri, 16 Jan 2004, Ross Vandegrift wrote:
> On Thu, Jan 15, 2004 at 02:20:16AM -0600, David B Funk wrote:
> > If you SMTP reject the spam, it never hits your queue, so no problem
> > with the garbage piling up and no bombarding poor innocent 'joe-job'
> > victims. It's better than auto-deleting spam, as a legit message
> > that is accidentally mis-identified as spam gets returned to the
> > true sender and they can remedy the situation rather than wondering
> > what happened to their message.
>
> I hope you see the contradiction in the above paragraph.
>
> "no bombarding poor innocent 'joe-job' victims"
> "gets returned to the true sender"
>
> Easily forged, easily joe-jobbed, better to never reject.
No contradiction if you are -truely- using SMTP reject on your
incoming mail gateway.
To make sure that you understand what I'm talking about, I'll explain
what what happens in a true SMTP reject.
The remote client connects to my incoming SMTP gateway machine.
If you read RFC-2821, you'll see the SMTP protocol steps that
the remote machine and my (or any) SMTP server go thru. During
that sequence, if my server returns a '550' response code, the
transaction is terminated, the remote machine is left with the
message and my server has no responsibility for it. (IE the
message never even gets past my 'front door').
This means that it is -NOT- in my mail queue, there is nothing
for my server to even think about trying to return to somebody.
If I reject a message, the sender and recipient addresses (forged
or real) are of no consequence to my server. Think of it like having a
'smart' ip-filter on your mail server. The remote machine is prevented
from handing the message to you at all.
In the case of a legit message that FPs above my reject threshold,
the sender's mail server is left holding the message and it has the
responsibility of returning it to them, so they get their messsage back.
There is one special case where this does not work, that of the
filtering machine not being the border gateway. IE if you (or some
other party acting in your behalf such as your ISP) have some
external server that accepts everything addressed to you and then
forwards the messages in to your filter machine. Then if your filter
machine rejects the trash, the external server is stuck with the
garbage and it will try to bounce them back.
However the OP was asking about an incoming filter machine and that
was the case that I was addressing.
>
> I had spamass-milter setup to reject for a while, and I found that my
> queues were always full. As I looked into it, I realized they were
> full of errors, just waiting to be crapflooded onto some poor-sod-like-me's
> mail server.
If you find crap messages (ones above your reject threshold) in your
queue on the filter machine, then you are -not- doing true SMTP rejects
(regardless of what your configuration claims).
Now I have my milter set to tag spam at 6.0 and reject at 20.0.
So there is a range of spam (6-20) that will be in my queue to
be delivered. (I do that in case of FPs.)
I've been hacking sendmail stuff for almost 20 years now, started
doing anti-spam filtering in the mid-90's. At that time, doing SMTP
rejects was the only thing that was easy to do, so it is second
nature to me.
Dave
--
Dave Funk University of Iowa
<dbfunk (at) engineering.uiowa.edu> College of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center
Sys_admin/Postmaster/cell_admin Iowa City, IA 52242-1527
#include <std_disclaimer.h>
Better is not better, 'standard' is better. B{
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Spamassassin-talk mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/spamassassin-talk
