[milters] Archive

Lists Index Date Thread Search

Article: 1178
From: Anthony Howe
Date: 2006-10-13 06:24:49 -0400
Subject: Re: M-ID milter

Removal...........: milters-request@milter.info?subject=remove
More information..: http://www.milter.info/#Support
--------------------------------------------------------

(I'm travelling and this post expired before I could moderate it. Resent 
by ACH for Mathias Koerber).

Anthony Howe said the following on 30/9/2006 15:03:
 > > Mathias Koerber wrote:
 >> >> is there a milter which can examine the Message-ID of outbound
 >> >> addresses, store it for a configurable period and then allow
 >> >> incoming mails which reference a thus listed M-ID?
 >> >>
 >> >> This should ideally work in conjunction with milter-gris or such.
 > >
 > > Something like this is planned for a milter-null enhancement. In the
 > > mean time, look at milter-abook. Something like this though will not
 > > work for grey listing because grey-listing is a pre-DATA filter, while
 > > what you propose is a post-DATA filter action. Once you issue 354 to
 > > DATA and receive the final dot, the only choice you have is to accept,
 > > reject, or discard the message; you cannot temp. fail. This is 
according
 > > to RFC 2821.
 > >
 > > See RFC 2821 section 4.1.1.4 DATA paragraph 4:
 > >
 > >                                       If the processing is successful,
 > >     the receiver MUST send an OK reply.  If the processing fails the
 > >     receiver MUST send a failure reply.  The SMTP model does not allow
 > >     for partial failures at this point: either the message is 
accepted by
 > >     the server for delivery and a positive response is returned or 
it is
 > >     not accepted and a failure reply is returned.
 > >
 > >

Hmm.

quoting from http://www.faqs.org/rfcs/rfc2821.html:

 > > 4.2.5 Reply Codes After DATA and the Subsequent <CRLF>.<CRLF>
 > >
 > >    When an SMTP server returns a positive completion status (2yz code)
 > >    after the DATA command is completed with <CRLF>.<CRLF>, it
accepts
 > >    responsibility for:
 > >
 > >    -  delivering the message (if the recipient mailbox exists), or
 > >
 > >    -  if attempts to deliver the message fail due to transient
 > >       conditions, retrying delivery some reasonable number of times at
 > >       intervals as specified in section 4.5.4.
 > >
 > >    -  if attempts to deliver the message fail due to permanent
 > >       conditions, or if repeated attempts to deliver the message fail
 > >       due to transient conditions, returning appropriate 
notification to
 > >       the sender of the original message (using the address in the SMTP
 > >       MAIL command).
 > >
 > >   When an SMTP server returns a permanent error status (5yz) code after
                                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
I believe this to be a mistake and that it should read 'transient
error status (4xy)' as the permanent case is discusses 2 paragraphs
down, and this paragraph talks about requeuing.
Should that interpretation be correct, it is permitted to issue a
temp-failure after the final '.'!

 > >    the DATA command is completed with <CRLF>.<CRLF>, it MUST NOT
make
 > >    any subsequent attempt to deliver that message.  The SMTP client
 > >    retains responsibility for delivery of that message and may either
 > >    return it to the user or requeue it for a subsequent attempt (see
 > >    section 4.5.4.1).
 > >
 > >    The user who originated the message SHOULD be able to interpret the
 > >    return of a transient failure status (by mail message or otherwise)
 > >    as a non-delivery indication, just as a permanent failure would be
 > >    interpreted.  I.e., if the client SMTP successfully handles these
 > >    conditions, the user will not receive such a reply.
 > >
 > >    When an SMTP server returns a permanent error status (5yz) code 
after
 > >    the DATA command is completely with <CRLF>.<CRLF>, it MUST NOT
make
 > >    any subsequent attempt to deliver the message.  As with temporary
 > >    error status codes, the SMTP client retains responsibility for the
 > >    message, but SHOULD not again attempt delivery to the same server
 > >    without user review and intervention of the message.


Mathias



-- 
Anthony C Howe          Skype: SirWumpus                    SnertSoft
+33 6 11 89 73 78         AIM: SirWumpus    Sendmail Milter Solutions
http://www.snert.com/     ICQ: 7116561
     http://www.snertsoft.com/

Lists Index Date Thread Search