spf-discuss
[Top] [All Lists]

Re: SRS integration with qmail (was: A couple of thoughts)

2004-02-17 13:27:08
----- Original Message ----- 
From: "Greg Wooledge" <greg(_at_)wooledge(_dot_)org>
To: <spf-discuss(_at_)v2(_dot_)listbox(_dot_)com>
Sent: Tuesday, February 17, 2004 1:34 AM
Subject: Re: SRS integration with qmail (was: [spf-discuss] A couple of
thoughts)

Seth Goodman (sethg(_at_)GoodmanAssociates(_dot_)com) wrote:

1) How will SRS-unaware MUA's display the From: address, Reply-to:
address, etc. for SRS sender addresses to the user?  Will this be
intelligible to an SRS-unaware human?

It should not. As Shevek astutely pointed out, mailing list and SMTP
envelope "speak" belong to two different layers. Unless someone seriously
broke their configuration, the former should not be affected by the latter.

I just finished implementing SRS, system-wide. Now all outgoing mail, for
all domains I host, has an SRS signed envelope-from. And the Milter takes
cares of weeding out invalid bounce messages (along the lines of what we've
been discussing from the last few days). So, far, everything goes
wonderfully well.

None of the normal MUA headers are affected by this technique. I only
change the envelope sender, which most (all recent?) MTAs will add to
messages as "Return-Path:". End users will typically never see it at
all, unless they use the "Show all headers" features of their MUAs.

You are forgetting DSN. :) When dealing with DSN, the SRS signed
envelope-from will find its way into the MUA headers. Like so:

----------------------------------------------
Return-Path: <MAILER-DAEMON(_at_)asarian-host(_dot_)net>
Received: from localhost (localhost)
 by mail.asarian-host.net (8.12.11/8.12.11) id i1GKfpeL004002;
 Mon, 16 Feb 2004 21:41:51 +0100 (CET)
 (envelope-from MAILER-DAEMON)
Date: Mon, 16 Feb 2004 21:41:51 +0100 (CET)
From: Mail Delivery Subsystem <MAILER-DAEMON(_at_)asarian-host(_dot_)net>
Message-Id: <200402162041(_dot_)i1GKfpeL004002(_at_)asarian-host(_dot_)net>
To: SRS0+0Iz/shlm=Cw=asarian-host(_dot_)net(_at_)?Ê¡Ëè?Ö3¾O̪éßø
MIME-Version: 1.0
Content-Type: multipart/report; report-type=delivery-status;
 boundary="i1GKfpeL004002.1076964111/asarian-host.net"
Subject: Returned mail: see transcript for details
Auto-Submitted: auto-generated (failure)

   ----- The following addresses had permanent fatal errors -----
someone(_at_)somewhere(_dot_)com
    (reason: 553 5.3.0 <someone(_at_)somewhere(_dot_)com>... No such user)
----------------------------------------------

Apart from the cosmetic matter of having an odd looking address in the To:
header, this minor aesthetic discomfort does not mean SRS breaks things. It
just means there are conditions where the SRS address becomes visible to the
MUA.

N.B. Developers who implement SRS into sendmail should be especially aware
of possible DSN issues, because DSN bypasses Milters altogether. So, if you
defined a "catchall" virtusertable entry, like so:

SRS0+*(_at_)asarian-host(_dot_)net    admin

Then this will break delivery with DSN! Because the mailer daemon, bypassing
any and all Milters, will then always deliver to "admin" (as specified, of
course). So, I changed it to this, instead:

SRS0+*(_at_)asarian-host(_dot_)net    bounce

Where "bounce" is an alias, like so:

bounce: "| /usr/local/bin/perl /etc/scripts/bounce.pl"

That way, the piped "bounce" script handles SRS bounces, and makes the
proper maildrop. The bounce address itself, btw, is made to respond "Unknown
user" via the Milter, so it is inaccessible from the outside.

Perhaps not just sendmail people should test DSN handling for SRS addresses;
just to avoid nasty surprises. :)

- Mark

        System Administrator Asarian-host.org

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