Fighting spam via greylisting

USM Bish bish at
Wed Apr 25 08:13:33 PDT 2007

On Wed, Apr 25, 2007 at 12:04:19PM +0300, Ag. D. Hatzimanikas wrote:
[ some snipped ]
> The  logic  behind greylisting  is  rejecting  email with  a
> temporary error code -- which is  defined in RFC 821 [1] and
> should be honored by the moderns MTA's-- so:
>    -  Any "well  behaved" [2]  MTA  will try  to resend  the
>    email, which is exactly what we want.
>      But the 450 code is  described as: User not active now.
>      Isn't  this (when  with our  software return  450) some
>      kind of a violation? Personally  I would like an answer
>      about  that, because  quite  possible, as  a novice  in
>      these matters, I'm missing something.
>    -  The  spam  software  will see  the  error  code  (450)
>    and  quite possible  will not  try to  resend the  email,
>    considering as a dead connection.
[ more snipped ]

IIRC, usually  greylisting involves sending Err Code  451 (viz
Requested action  aborted: local  error in  processing). Since
this implies that  ATRN request cannot be processed  now, or a
temporary failure, most modern MTAs resend the mail on receipt
of Err 451.

OTOH, Err Code 450 is  "Request mail action not taken: mailbox
unavailable" (which is  perhaps what you mean  by saying "user
not active now"). This is  a serious error, and indicates ATRN
request  has  been *refused*.  MTAs  compliant  with RFC  822,
should not respond this.

Would this explain the missing link ?


More information about the lfs-dev mailing list