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.

-------
   _|_
  (_| |