Re: [dmarc-ietf] Sender vs From Addresses

Douglas Foster <> Thu, 25 March 2021 01:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D2F953A157C for <>; Wed, 24 Mar 2021 18:25:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.087
X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id nsY7togFuuUK for <>; Wed, 24 Mar 2021 18:25:05 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::e35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EF0BA3A157A for <>; Wed, 24 Mar 2021 18:25:04 -0700 (PDT)
Received: by with SMTP id e5so43414vse.4 for <>; Wed, 24 Mar 2021 18:25:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=77lOrMMOt3YDHY5TU+K7k7PW1ArMUNUBMeNQVyXMZIw=; b=es7Z+b3YtCF7LQDTIvhgdART54GdY/4L5DgZAzuKUBe8X8hOCYmYT/aac1qfjqcdq5 a6Ac2NNNe6fZV3RfOAFcHKO5j/OJTvsdrbiOwQ8zpT+yS63r1hwaQTk0IOeLOAxVNdod x3G/hjGowiRMwoYlsTbdwSB5jgM1YW27xnwrCL4y+/Lye2xasTzLd5eZZ9C3Mi3IeS7p JzozFOa7HXQPb3Ya2fW4zgN/U7VeNXnlXZbH3Q/Xp9O0+jZUrehNknC2GIAHQTJdYZGU IIsHzB+iEINm1VFeIf8QUafgu2zQpjfNwQX+PlwR1vf+6tT0ak6q1rhmAtx0z1zxOeb0 PGJA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=77lOrMMOt3YDHY5TU+K7k7PW1ArMUNUBMeNQVyXMZIw=; b=RFSRME7r+zYKvjieR9R6eKVdqGwMOYMWHZe2zUcs3SompNy8YekO+UrsYaieYtik4H MCAjl3jEVyGqi8sQjzpFCB2Nn80dcxY97c/5dys10E8JHhCpiXcY6v6RjVPHxswvVhRC dE9vuv/Rqg2laLHamFGiEMQEypEB5d0XOUFajYE3bb1B1U3Cyi5wE/sp5Xf8IyGddtjG 7TCmbJwj5IMxn4c1AaqLHzLT54DZCS7eBmf882c2F47pXlOciR3jCbKKer3CK8SUvc6A vJdSPUgN5+/OM50QEhfUIy4hHo6xpj32IMTxvsb+2POvwR/bOZ1ZVhBRbTafC7ZCnM7a 96SA==
X-Gm-Message-State: AOAM533NVu41HK2+SlBugQqR3TUecbd6UVE2VB9shBefk8VfQwy3ZQcB 2wGM8d+gOyzOOtE+bpT+iyiROkdmCCXUkvlIrQESvo4ITeI=
X-Google-Smtp-Source: ABdhPJzsu8hstTPrJG+01hc2kVyfF5Pr4ojw0SapTjFuaxLPH03p1gOH67Xup5fcgBIxMPV8hGsY/oXEZoLv+lkf5Lg=
X-Received: by 2002:a67:fc8e:: with SMTP id x14mr3662539vsp.25.1616635503448; Wed, 24 Mar 2021 18:25:03 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Douglas Foster <>
Date: Wed, 24 Mar 2021 21:24:53 -0400
Message-ID: <>
Content-Type: multipart/alternative; boundary="000000000000ea168505be52483a"
Archived-At: <>
Subject: Re: [dmarc-ietf] Sender vs From Addresses
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 25 Mar 2021 01:25:10 -0000

> Calendar invites are a special case which requires a task-specific
> solution.
> The larger problem is with forwarding.   Forwarders want a way to reliably
> identify themselves so that their forwarded traffic is given a favorable
> reputation.   Authentication based on the “Sender” header is one variant on
> this objective.    The theoretical obstacles to this goal are substantial.
> For a general solution, we must assume that the forwarder receives a
> message stream which includes both wanted and unwanted messages.     We can
> also assume that the forwarding organization and the final recipient
> organization have different spam filtering rules.
> If the filtering rules of the forwarding organization are stricter than
> the receiving organization, then the recipient will miss some messages that
> should actually be delivered, leaving both originator and recipient feeling
> unhappy with the forwarder.   In the general case, this incents the
> forwarding organization to have relatively weak filtering rules.
> In the more likely case that the filtering rules of the forwarding
> organization are weaker than the recipient organization, then the
> forwarding organization will accrue a reputation as unreliable, the source
> of some spam.
> Additionally, the process of forwarding hinders the ability of the
> recipient organization to filter based on the actual sender.    The process
> of forwarding hides the message source behind the forwarder identity,
> obscuring information that would have been used to evaluate the message if
> it had been sent directly.  Consequently, we have a message source that is
> known to send some spam, combined with insufficient tools for
> distinguishing between trusted and malicious originators.
> To solve these problems, a forwarded message will need to be evaluated
> using both the forwarder identities and the originator identities.    That
> process will require scanning the entire header structure, particularly the
> entire Received chain, which should then be correlated with any changes
> made to the RFC5321.MailFrom address or RFC5322.From address.   My opinion
> is that the current header structure lacks the identifiers necessary to do
> this correlation, even if the submitting servers are eager to supply
> whatever is desired.
> The trust problems are aggravated by the inability to verify the accuracy
> of the Received header, SRS rewrites, or mailing list modifications.    If
> recipients begin using unverifiable header elments for whitelisting, then
> spammers have an incentive to construct fraudulent header elements.    If
> recipients only use this information for blacklisting, then the needs of
> forwarders have not been sufficiently satisfied.
> Therefore, I conclude that forwarders will always be dependent on
> recipient organizations who are willing to create local policies to handle
> the traffic from a trusted forwarder differently than traffic from an unrecognized
> forwarder or unforwarded messages from sources with authentication FAIL.