Re: [apps-discuss] generating DSNs (RFC3464) signed with S/MIME?

Claudio Allocchio <> Sun, 11 January 2015 15:48 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 0F5211A6FCB for <>; Sun, 11 Jan 2015 07:48:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.131
X-Spam-Status: No, score=-0.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8ZuEFcjb0Yea for <>; Sun, 11 Jan 2015 07:48:17 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2A2CC1A6F7C for <>; Sun, 11 Jan 2015 07:48:16 -0800 (PST)
Received: internal info suppressed
Date: Sun, 11 Jan 2015 16:48:11 +0100
From: Claudio Allocchio <>
X-X-Sender: claudio@mac-allocchio3.local
To: Ned Freed <>
In-Reply-To: <>
Message-ID: <alpine.OSX.2.02.1501111634060.18020@mac-allocchio3.local>
References: <alpine.OSX.2.02.1501111600270.18020@mac-allocchio3.local> <>
User-Agent: Alpine 2.02 (OSX 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=cyrus; t=1420991292; bh=PRVBMXaUEy4lTiQz6IwvdGZr0BPxvrWQTAOyoB+bnvc=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=GGtllF9VbWA14lCiZGeKJqjgoB+aCc7zImRU4SNOyVWgNQiqQpDKQq8iR+dUGuJKn QbssSRzumky4LFY+ayoUYDOwP42ZY9gCZ9bcaLsIsxx6jVciotkzV2N+l3N6X/oBd2 XhjhDafSxj+OM6yBBQZzgaCrbsYNa7Y6OwX24f2Q=
Archived-At: <>
Subject: Re: [apps-discuss] generating DSNs (RFC3464) signed with S/MIME?
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 11 Jan 2015 15:48:19 -0000

Hi Ned,

On Sun, 11 Jan 2015, Ned Freed wrote:

>> Hello all,
>> I've been explicitly asked the question if the correct way to avoind the
>> possible forgery of DSNs described in the Security Consideration sections
>> of RFC3464 is to have the MTA sending S/MIME signed receipts instead of
>> plain MIME/Multipart...
>> Well, in theory that's the correct answer, and it looks more an
>> implementation/support problem of MTAs than realted to protool
>> specifications... it is just combining two specifcations to get the
>> desidered result IMHO... and veryfying that there are s/w implementation
>> which allow the administrator to do that... but better ask a wider opinion
>> before answering...
> What mechanism are you supposed to use to validate the signature on such
> receipts? Absent a specification for such a mechanism - which as far as I 
> know
> does not exist - I don't see how this really helps.

I was thinking of a server-certificate issued to the MTA making the 
signature, and to use the certificate to sign with S/MIME the DSN message. 
So... is it not enough to use the same signiature verification mechanisms 
used when a human user send an S/MIME signed message? Or am I wrong?

> The other question is what sort of forgery are you worried about? If you're
> talking about spam DSNs, then that can be dealt with by correlating DSNs with
> the messages a user actually sent.

no, this was not the case.

> If, OTOH, you're worried about someone sending fake DSNs saying a message
> was bounced when it wasn't, or received when it wasn't, then I think a better
> understanding of the actual threat you're concerned with is needed before
> suggestions can be made.

This was the case being asked indeed... the latter:

- a message is sent asking for a DSN.

- the message indeed is NOT delivered to the actual recipient (for example 
it is intercepted by somebody else via spoofed DNS MX records, or other 
DNS spoofing mechanisms), but the man-in-the-middle MTA issues a forged 
positive DSN to the sender.

- the sender is convinced his message was delivered, but indeed it was 

In such a case, of case, there is of course the verification inside the 
MTA log of the real recipient which can identify the forgery, but the 
sender usually does not have access to this information, and trusts what 
the DSN he/she received say.

(the other case, e.g. the message was delivered, but a forged negative DSN 
is issued, is not a real issue in such a case).

Does this clarify the issue?

> 				Ned

Claudio Allocchio             G   A   R   R
                         Senior Technical Officer
tel: +39 040 3758523      Italian Academic and       G=Claudio; S=Allocchio;
fax: +39 040 3758565        Research Network         P=garr; A=garr; C=it;

            PGP Key: