[Greylist-users] Another idea for greylisting (fwd)

[Evan Harris]

> > The very *first* time you see a new "relationship", do the tempfail after
> > the end of the DATA phase, and then you have the mail to inspect.  You
> > can then send it to DCC, Razor, etc.
>
> If the idea is to deny spammers our bandwidth, then this is bad.  By
> accepting the mail, we paid for the bandwidth.  If the idea is to not allow
> any spam to the end user, then I think this is an interesting idea.
>
> Will it deter the spammer in the second case?  I think not.  They don't know
> who implements greylisting, and in the second case, their email is as good
> as sent.  They delivered their payload, and depending on the policy behind
> the MTA, their email may or may not reach their target.

I think you're misunderstanding the suggested implementation.  All he's
saying is to allow the mail transaction to get far enough to be able to see
the body of the message, but still failing the delivery with a tempfail
code.  The spammer still sees a failure, and we don't store the mail or
deliver it, we just hash it and send the signature(s) to those other
entities.

Granted, it will cost the extra bandwidth of recieving the body if this were
done, but it could very easily be used based on a local configuration
parameter, so people could "pick their poison".

> 1) Are we out to make it as difficult for the spammers as possible?
> Or:
> 2) Are we out to make it as easy as possible for the end user?
> Or:
> 3) Are we out to minimize our bandwith usage to spammers?

And 4) Catch the most spam.

My intention is to do everything possible to do all four.  But this looks
like a good reason why some people who might use the system may want to
forsake a little bit of 3 in order to give a little more to 2 and 4.

Evan