Re: SRS implemenation in sendmail

Tom Lahti wrote:

> In the page http://asarian-host.net/srs/sendmailsrs.htm an SRS
> integration with sendmail is presented.  It is implied in the opening
> paragraphs that after implementation something like the following
> would happen:
>
>  >>> MAIL from: <>
> <<< 250 2.1.0 <>... Sender ok
>  >>> RCPT To:<[email protected]>
> <<< 250 2.1.5 <[email protected]>... Recipient ok
>  >>> DATA
> <<< 550 5.7.1 Bounce address not SRS signed!
>
> However, this is NOT the case.  There are no modifications to the
> sendmail config file presented on the web page, which would generate
> a 550 error after the data phase if the bounce recipient is not SRS
> signed.

My page also reads:

"You could certainly put a front-end Milter at the gate. Especially so, if
you wish to implement the above outlined "empty envelope-from + no SRS
signed recipient + DATA phase" anti-spammer policy. But that falls outside
the scope of this document, which is to integrate SRS functionality into
sendmail."

> How can this presentation be amended to achieve the goal of rejecting
> bounces that are NOT signed AT ALL?  This would need to be invoked:
>
> 1) Only if the envelope is <>,  and
> 2) Only if the recipient is unsigned (either valid or invalid), and
> 3) only after we enter the DATA phase.
>
> Since ParseLocal is called on the recipient before the possible DATA
> phase, we can't reject the mail there.  I am at a loss as to how to
> do anything when we enter the DATA phase.

To actually reject right after the DATA command is tricky. In practice, you
would have to wait out the DATA phase, and reject at its completion.
Officially, per RFC 2821, sending a 550 response code after DATA is no
longer appropriate, and this should be 554 ("Transaction failed"). I should
change my documentation to wit.

A Milter is really a good place for implementing such a policy, as it gives
you the nice "overiew" of all conditions which need to be met before you
reject.

> It might be sufficient to add the envelope sender to the ARGV list
> for the program invoked by is_srs and rewrite the recipient to
> "/dev/null" ...  If its a valid probe, it won't matter, and if
> there's DATA later then it'll get delivered to the bit bucket.  The
> only thing is then we allow the DATA to be transmitted even if we're
> going to drop it anyway.

I will see about adding a script that actually does implement the outlined
anti-spammer policy. Though I doubt the DATA phase can actually be
circumvented from sendmail.cf.

- Mark

        System Administrator Asarian-host.org

---
"If you were supposed to understand it,
we wouldn't call it code." - FedEx