You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Rick Macdougall <ri...@ummm-beer.com> on 2007/08/01 00:20:47 UTC
Re: How would you provide a 554 rejection notice for spam?
John D. Hardin wrote:
> On Tue, 31 Jul 2007, mouss wrote:
>
>> running SA at smtp time requires that the client does not timeout.
>> so you'd better scan fast! you're also more subject to DOS (your
>> smtp listeners are busy). compare this to queue and filter...
>
> okay, here's a sick idea:
>
> (1) MTA completes the SMTP exchange and responds with a 4xx after DATA
> finishes.
>
> (2) MTA passes message off to SA, then stores a hash of
> message-ID/score. MTA then discards the message.
>
> (3) When the remote MTA retries (if it retries) then the MTA looks up
> the score in the hash and decides whether to 200 or 5xx the message.
>
> All of the benefits of both methods! :)
>
Sort of like grey listing, which I do run on my personal domain, but I
wouldn't use that method because of the inherent delay caused by the 4xx
retry.
Neat idea though.
Regards,
Rick
Re: How would you provide a 554 rejection notice for spam?
Posted by Per Jessen <pe...@computer.org>.
Rick Macdougall wrote:
> Sort of like grey listing, which I do run on my personal domain, but I
> wouldn't use that method because of the inherent delay caused by the
> 4xx retry.
Only happens once though.
/Per Jessen, Zürich
Re: How would you provide a 554 rejection notice for spam?
Posted by Duane Hill <d....@yournetplus.com>.
On Tue, 31 Jul 2007 at 18:20 -0400, rickm@ummm-beer.com confabulated:
> John D. Hardin wrote:
>> On Tue, 31 Jul 2007, mouss wrote:
>>
>>> running SA at smtp time requires that the client does not timeout.
>>> so you'd better scan fast! you're also more subject to DOS (your
>>> smtp listeners are busy). compare this to queue and filter...
>>
>> okay, here's a sick idea:
>>
>> (1) MTA completes the SMTP exchange and responds with a 4xx after DATA
>> finishes.
>>
>> (2) MTA passes message off to SA, then stores a hash of message-ID/score.
>> MTA then discards the message.
>>
>> (3) When the remote MTA retries (if it retries) then the MTA looks up the
>> score in the hash and decides whether to 200 or 5xx the message.
>>
>> All of the benefits of both methods! :)
>>
>
> Sort of like grey listing, which I do run on my personal domain, but I
> wouldn't use that method because of the inherent delay caused by the 4xx
> retry.
>
> Neat idea though.
I agree, neat idea. However, all email messages coming into the server
would be delayed. Unlike greylisting, where the connection is accepted
after the initial 4xx rejection.
-------
_|_
(_| |