Internet DRAFT - draft-vesely-fix-forwarding
draft-vesely-fix-forwarding
Network Working Group A. Vesely
Internet-Draft 10 July 2023
Intended status: Experimental
Expires: 11 January 2024
Agreements To Fix Forwarding
draft-vesely-fix-forwarding-01
Abstract
The widespread adoption of Domain-based Message Authentication,
Reporting, and Conformance (DMARC) causes problems to indirect mail
flows. This document proposes a protocol to establish forwarding
agreements whereby a mailbox provider can whitelist indirect mail
flows directed toward its users by maintaining per-user lists of
agreements.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 11 January 2024.
Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Vesely Expires 11 January 2024 [Page 1]
Internet-Draft Fix Forwarding July 2023
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terms Definitions . . . . . . . . . . . . . . . . . . . . . . 4
3. Note About Rewriting the Bounce Address . . . . . . . . . . . 4
4. Underscored FixForwarding DNS Resource Record . . . . . . . . 5
5. Forwarding Agreement Web Form . . . . . . . . . . . . . . . . 7
5.1. The Transistor Metaphor . . . . . . . . . . . . . . . . . 7
5.2. Form Fields . . . . . . . . . . . . . . . . . . . . . . . 7
6. Agreement Management . . . . . . . . . . . . . . . . . . . . 9
7. Messages to the Base . . . . . . . . . . . . . . . . . . . . 10
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 13
10. Security Considerations . . . . . . . . . . . . . . . . . . . 13
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
12.1. Normative References . . . . . . . . . . . . . . . . . . 14
12.2. Informative References . . . . . . . . . . . . . . . . . 15
Appendix A. No-Munging Method . . . . . . . . . . . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction
The ability to send messages to anyone without prior agreement is a
feature at the base of the success of Internet mail. It also exposes
a way to abuse, though. Domain-based email authentication can limit
abusive behavior by enabling receivers to unambiguously attribute
responsibility of messages, and thereby to develop domain reputation.
However, indirect mail flows, such as mailing lists and aliases are
seriously hindered by such authentication practices (see [RFC7960]).
Although they constitute a minor part of the global mail traffic,
such hindrance poses a problem, which is what the present protocol
attempts to fix.
Many mailing lists break DomainKeys Identified Mail (DKIM) signatures
([RFC6376]) by adding a subject tag or a message footer. External
aliases break Sender Policy Framework (SPF) ([RFC7208]) if forwarders
don't change the bounce address, or break its alignment with the
From: header field if they do. In both cases, they break Domain-
based Message Authentication, Reporting, and Conformance (DMARC)
([RFC7489]) if there is no DKIM signature.
Rewriting the very From: field, an operation known as From: munging,
is a sender side solution to this problem, adopted by most mailing
lists; see Section 4.1.3.1 of [RFC7960] for a detailed description.
Aliases, instead, can be avoided by having the target pull messages
using a mail retrieval protocol rather than pushing them via SMTP.
As an alternative, this document proposes a cooperative method that
Vesely Expires 11 January 2024 [Page 2]
Internet-Draft Fix Forwarding July 2023
hinges on the peculiarity that both of these forwarding methods
require settings which produce well recognizable mail flows. To
present by example, let's consider the procedure whereby
alice@example.com subscribes to the mailing list
participants@lists.example.org. The first three steps are a well
known practice known as *confirmed opt-in* (COI). The extra steps
are introduced by this protocol:
1. Alice subscribes to the list, either by visiting example.org web
site or by sending a request to the list manager.
2. The mailing list manager (MLM) sends a confirm message with a
unique token to be returned for confirmation, either via web or
via mail.
3. Alice confirms the subscription.
4. The MLM looks up _fixforwarding.example.com on the DNS to check
if Alice's provider supports forwarding agreements (see Section 4
for the TXT record format). If found, the MLM applies for a
permission to send mailing list messages that may fail DMARC
checks (see Section 5 for the web form it has to fill).
5. Upon receiving the MLM application, example.com sends a message
to its user Alice, asking whether she agrees to receive that
specific mail flow.
6. Alice confirms to her provider too.
7. Example.com adds participants@lists.example.org to the list of
forwarders that Alice agreed upon. Then, it confirms to the MLM
that the agreement is set up.
8. The MLM modifies Alice's subscription options removing From:
munging for messages sent to her.
9. Example.com recognizes messages belonging to this mail flow by
(1) authenticating example.org and (2) checking the List-ID:
header field. As this matches Alice's list of exemptions, DMARC
failures can be safely ignored.
Steps 4 to 9 are discussed in detail in the following sections. For
software requirements, note that step 8 implies the ability to
configure From: munging per subscriber; Appendix A proposes a method
to achieve such effect. Step 9 requires that the DMARC verifier be
able to do per-user exemptions as described in Section 6
Vesely Expires 11 January 2024 [Page 3]
Internet-Draft Fix Forwarding July 2023
2. Terms Definitions
The term *forwarder* is used to mean the entity that forwards
messages, which is either a *mailing list* or an *alias*, as defined
in Section 3.1 of [RFC5321]).
A *receiving domain* is a domain which receives messages sent by a
forwarder.
*Signers* and *verifiers* are defined by DKIM ([RFC6376]). The use
of the term *Mailing List Manager*, almost always abbreviated *MLM*
follows [RFC6377]. A MLM is a kind of *Mediator* in [RFC5598]
parlance. It is usually composed of a Message Transfer Agent (MTA)
with the usual suite of tools plus the mailing list specific
software.
*Message* is defined in [RFC5322]. It consists of a *header* made up
of one or more *fields*, and a *body* possibly composed of various
MIME *entities*, the latter being defined in [RFC2045] and
companions.
We use *colon* (:) to indicate header field names, as in From:, To:
and the like.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. Note About Rewriting the Bounce Address
Traditionally, alias expansion re-injects messages in the mail system
changing just the envelope recipient address. That is, without
rewriting the bounce address, a.k.a. envelope sender. This is what
SMTP [RFC5321] prescribes. However, from an authentication
perspective, this doesn't always work, because some MTAs reject SPF
failures —those matching a -all directive (see [RFC7208])— during the
early stages of the SMTP protocol; that is, before DKIM or ARC
[RFC8617] can be verified.
It is handy to leave the bounce address intact in order to have the
message author notified in case of failed delivery, which increases
email reliability. However, nowadays MTAs try and minimize
backscatter by avoiding to accept messages that can bounce. On the
other hand, transient failures, such as mailbox full, became less and
less frequent. If a delivery fails because the target mailbox was
deleted, the forwarding setup has to be dismantled. A broken alias
Vesely Expires 11 January 2024 [Page 4]
Internet-Draft Fix Forwarding July 2023
which unflaggingly generates bounces to any bounce address is akin to
an open relay. Albeit limited to non-delivery notifications, it can
be exploited for spamming. In order to avoid playing such role, a
receiver can carefully verify the bounce address before accepting a
message, so expect your target to behave accordingly.
We recommend to replace the bounce address with the internal address
of a human or a robot which can understand what to do. Nevertheless,
this protocol provides for a way to enter into an agreement which
covers traditional alias expansion. According to Appendix D of
[RFC7208], domains consult a whitelist if they reject SPF "fail"
messages before receiving the message data. If the whitelist they
consult is a public DNS-based whitelist (DNSWL, [RFC5782]) which
includes the forwarder's IP address, then traditional alias expansion
can work even in the face of strict SPF policies.
To recap, an MTA can check SPF after the MAIL but before the DATA
SMTP commands. If the result is "fail", the MTA consults one or more
DNSWLs. If the sending IP address is whitelisted, then the MTA
delays the decision to reject to a later stage, when the message
content is received and DKIM or ARC verified. Thus, an agreement
providing for traditional alias expansion is possible if either one
of the following two conditions holds:
1. The target MXes consult public DNSWLs and the forwarder is
subscribed to at least one of them, or
2. the target MXes never reject before receiving and evaluating the
message content.
If and which of these conditions holds can be determined based on the
dnswl= tag declaration, as described in Section 4.
4. Underscored FixForwarding DNS Resource Record
Domains participating in this protocol notify it to all interested
parties by publishing an "underscored" resource record named
_fixforwarding. According to [RFC8552], this record is labeled as a
subdomain of the domain it refers, which is the domain-part of the
pertinent email addresses.
The record contains the conditions that an applicant MUST meet before
applying for an agreement as well as an URI to post requests to.
Requests details are specified in Section 5.
Vesely Expires 11 January 2024 [Page 5]
Internet-Draft Fix Forwarding July 2023
The format of the _fixforwarding record follows the extensible "tag-
value" syntax for DNS-based key records defined in DKIM [RFC6376].
The folding white space terminal, FWS, is also defined there. The
following tags are defined here:
*auth*
Authentication method used to identify the forwarder's domain;
OPTIONAL, by default the method is ARC ([RFC8617], but DKIM is
allowed as an alternative. A forwarder MUST implement the
required method before applying.
ABNF:
rec-auth-tag = %s"auth" [FWS] "=" [FWS] rec-auth-tag-method
rec-auth-tag-method = %s"arc" / %s"dkim"
*dnswl*
Either a comma-separated list of DNSWLs (see [RFC5782]) that the
domain's MXes consult before rejecting SPF failures at the early
stages of SMTP transactions, or the keyword "n.a.", for not
applicable; OPTIONAL, by default an empty list. See Section 3.
An empty list, the default, means this option is not available;
that is, forwarders MUST change the bounce address to an SPF valid
one. The "n.a." keyword means the opposite; that is, forwarders
MAY leave the original bounce address intact. One or more domains
mean the conditional acceptance; that is, the DNS name that
results by prepending the reverse IP address of the forwarder to
one of those domains resolves to an A IP address when queried.
ABNF:
rec-dnswl-tag = %s"dnswl" [FWS] "=" [FWS] [rec-dnswl-tag-opt]
rec-dnswl-tag-opt = rec-dnswl-tag-list / rec-dnswl-tag-na
rec-dnswl-tag-list = domain *("," domain)
rec-dnswl-tag-na = %s"n.a."
Where domain is imported from [RFC5322]. Each domain of the list
is a DNS zone that can be queried by prepending reversed IP
addresses. For best interoperability, it is RECOMMENDED to use
organizations that admit free subscriptions.
*post*
This is the URI to post web form requests to. Web format is
described in Section 5. This is an HTTPS or HTTP URI.
ABNF:
Vesely Expires 11 January 2024 [Page 6]
Internet-Draft Fix Forwarding July 2023
rec-post-tag = %s"post" [FWS] "=" [FWS] rec-post-tag-uri
rec-post-tag-uri = https-URI / http-URI
Where https-URI and http-URI are imported from [RFC9110].
5. Forwarding Agreement Web Form
Receiving domains participating in this protocol set up a web form
whereby forwarders can apply for a permission to send messages that
may fail DMARC checks. Forwarders who wish to enter an agreement
with the receiving domain fill the form supplying the values
requested, chiefly email address contacts. As there is a predefined
set of fields, applicants can prepare a script which runs
automatically when the availability of the form is detected by the
_fixforwarding resource record, and the conditions therein are met.
Yet, receiving domains SHOULD provide at the same post= URL an HTML
form to be filled manually, so that it is possible to enter an
agreement also without developing a special script. When no value is
posted the form displays the empty fields to be filled; when values
are posted it displays the results. Posted values can be encoded
using either the application/x-www-form-urlencoded or the multipart/
form-data media types (see [RFC7578]).
Normal HTTP rules [RFC9110] apply. In particular, receiving domains
SHOULD check that the values posted are acceptable and return a 400
HTTP status code otherwise. Organizations that need to limit access
to verified applicants MAY require an authorization, and return
status code 401 if it is not present. In that case, the HTML form
page SHOULD explain or point to an explanation of how can generic
operators obtain the necessary authorization. If everything is fine,
the HTTP server stores the values for later processing and returns
status code 202. The resulting agreement status will be sent to the
base address of the applicant after checks are completed. Keep in
mind that this may take a human lapse of time.
5.1. The Transistor Metaphor
Three email addresses play a key role, the entry point where the
messages to be forwarded arrive, the target address which is the
subject of the agreement, and the base address where the state of the
agreement is sent, including the results of the form submission.
Following a transistor metaphor we name these fields *collector*,
*emitter* and *base* respectively.
5.2. Form Fields
*abuse*
Vesely Expires 11 January 2024 [Page 7]
Internet-Draft Fix Forwarding July 2023
The abuse-team or similar entity email address, where complaints
about perceived forwarder's misbehavior can be sent.
*agreement-id*
A globally unique string that identifies a request and the related
agreement. This has the syntax of a Message-ID field [RFC5322]
and is RECOMMENDED that the right-hand side contain the same
domain identifier used for signatures, if it is able to guarantee
the uniqueness of the left-hand side within itself. Angle
brackets not to be included.
*base*
The forwarder's email address where the receiving domain sends the
agreement acceptance, rejection, renewal or cancellation. This
address SHOULD have the same domain used for signing. These are
machine-readable email messages that may contain a human-readable
part. It is possible to check the base address by an apposite
message type. The message format is described in Section 7.
*collector*
The mailing list post address, or the address that the alias is
attached to. This address SHOULD have the same domain used for
signing.
*domain*
The forwarder's domain to be authenticated by the receiver. It is
the domain indicated in the d= tag of DKIM-Signature: or ARC-Seal:
and ARC-Message-Signature: header fields, according to the auth
method (Section 4). The domain MUST match the trailing part of
the list-id. It is suggested that the two identifiers match as
much as practical.
*emitter*
The user-confirmed email address that subscribed to the mailing
list, or the target address of an alias. This address MUST have
the same domain where the _fixforwarding record was found.
*list-id*
Vesely Expires 11 January 2024 [Page 8]
Internet-Draft Fix Forwarding July 2023
List-ID:s are naturally present in mailing list, and identify the
list that the user subscribed to. For aliases, a list-id MUST be
created, for example by concatenating an encoded representation of
the collector and the signing domain. This is the globally unique
list-id identifier, which MUST be included in a List-Id: header
field, in angle brackets as specified by [RFC2919], in every
forwarded message. This field is needed to unequivocally identify
the mail flow. The trailing part of the list-id MUST match the
domain. The List-Id: header field SHOULD be signed. Failure to
do so can be exploited to damage MLM reputation by replaying
suitable messages.
*text*
Free text describing the forwarding reasons or circumstances.
This is intended to be presented to the user by the receiving
domain when asking for confirmation. It SHOULD NOT exceed 4K
octets and SHOULD NOT contain HTTP or HTTPS URIs.
*token*
An authorization token. HTTP provides a number of authentication
and authorization schemes, see Section 11 of [RFC9110] for an
overview. However, not all of them are supported by all browsers.
This field is meant to provide a last resort possibility.
6. Agreement Management
Request processing involves interaction with the user, therefore the
result can become available after some time. Asking for user
confirmation can also be an occasion to manage mailbox details such
as what folder or label would the user like to associate with the
mail flow. Mailbox providers can also implement a web application
that lists the status of all forwarding agreements. It would be
somewhat more reliable than the monthly subscription reminders, which
some call a distributed in time database.
It is beyond the scope of this document to stipulate for the
relationship between MLM's COI message and receiving domain's
confirmation. A MLM can send the COI message before or after sending
the form, or it can omit sending the COI message altogether, blindly
trusting the receiving domain.
The receiving domain MAY accept or reject the agreement. If it
accepts, it stores the form values that the forwarder supplied, so as
to be able to manage the agreement. The agreement-id is a good
candidate for the filename or database key used to retrieve that
data. Keep in mind that there is an agreement for each <collector,
list-id> pair.
Vesely Expires 11 January 2024 [Page 9]
Internet-Draft Fix Forwarding July 2023
To honor the agreement, a DMARC filter only needs two items of the
agreement data, the emitter and the list-id. For ARC, the filter
checks the validity of the chain and the validity of the ARC-Message-
Signature: whose d= domain matches the list-id (when oldest-pass is
set, it must not be bigger than the instance, i= of the list-id
signer). For DKIM, a valid signature with d= matching the list-id
assures of the message origin. Next, the DMARC filter checks whether
the pair <recipient, list-id> corresponds to an active agreement. If
the message is thus found to be part of an agreed upon mail flow, the
DMARC filter MUST exempt it from undergoing the DMARC policy
published by the message's From: domain. If the receiving domain
sends aggregate reports, the messages thus exempted SHALL be counted
under the trusted_forwarder PolicyOverrideType.
The receiving domain MAY extend the exemption to other recipients.
Otherwise, if a message is destined to more recipients, each one must
be the subject of a forwarding agreement.
After setting up DMARC exemptions, the receiving domain sends an
acceptance email to the base address of the forwarder. From that
moment, the forwarder can stop From: munging messages destined to the
relevant subscriber. The agreement can last indefinitely. However,
at any time, if the receiving domain suspects that the mail flow is
not active any more, it MAY send a renewal notice to check. The
agreement MUST be honored until the receiving domain sends a
cancellation. See Section 7 for the format of these messages.
The agreement SHOULD be canceled after the user unsubscribes from the
mailing list or when the mailbox is torn down. Conversely, a
cancellation should imply removal, or at least questioning the
forwarding itself, whether mailing list or alias.
7. Messages to the Base
There are five types of messages that can be sent by the receiving
domain to the forwarder base address. These messages define the
state of the forwarding agreement. Such state is determined at the
incontestable discretion of the receiving domain. The forwarder
SHOULD reply to these messages as a means to acknowledge their
reception. If the forwarder doesn't have any reference about the
agreement, it MAY either reject the message or give a negative reply
to it. Rejecting is handy if a forwarder implements a different base
address for each agreement. The receiving domain SHOULD re-send the
message once or twice if a reply or a bounce is not received within a
reasonable time (days). After 4-5 days with no response, the
agreement can be considered dead.
The message types are as follows:
Vesely Expires 11 January 2024 [Page 10]
Internet-Draft Fix Forwarding July 2023
*base-check* This message only acknowledges that the request was
received. It is OPTIONAL, as the HTTP return code suffices. The
real purpose of this message type is for the receiving domain to
check that the base address exists and see the DKIM signature of
the domain.
*acceptance* The receiving domain accepts the agreement. From the
time this message is received onward, messages can avoid From:
munging or, if allowed by the receiving domain, bounce address
rewriting.
*rejection* The receiving domain, presumably after user disavowal,
denies the agreement. Failed authentications can then be rejected
or quarantined. The forwarding itself should be questioned. A
new agreement SHOULD NOT be requested again unless further
interactions occur, such as the user unsubscribing and re-
subscribing.
*renewal* The receiving domain needs a confirmation that this
forwarding mechanism is still on. The forwarder should check that
the mechanism implied by the agreement is still active before
replying. Failure to reply can result in the agreement
cancellation.
*cancellation* The agreement is canceled. For mailing lists, the
user should have already unsubscribed. The alias should be
removed.
These messages are plain text messages with no attachments and no
MIME multipart entities. The agreement-id and the message type are
repeated in the Subject: and in the beginning of the body. The rest
of the body MAY contain any text.
ABNF:
msg-subject = msg-tag WSP agreement-id ":" [WSP] msg-type
msg-tag = "[FixForwarding]"
msg-body = agreement-id-line msg-type-line msg-rest
agreement-id-line = [CRLF] "agreement-id" ":" [WSP] agreement-id CRLF
msg-type-line = [CRLF] "deal" ":" [WSP] msg-type CRLF
msg-rest = *OCTET
msg-type = %s"base-check" / %s"acceptance" / %s"rejection" /
%s"renewal" / %s"cancellation"
agreement-id = id-left "@" id-right
subject = "Subject" ":" msg-subject CRLF
message = fields CRLF msg-body
Vesely Expires 11 January 2024 [Page 11]
Internet-Draft Fix Forwarding July 2023
Where WSP, CRLF and OCTET are imported from [RFC5234]; subject, id-
left, id-right and fields from [RFC5322].
Replies SHALL also be text/plain, retaining the Subject: and body of
the original message, possibly prefixed as is customary for Internet
mail, for example by prefixing the subject with "Re:" and body text
lines with "> ". Replies MUST properly set In-Reply-To: and
References: fields. The receiving domain can use those to match
replies with the original message. For negative replies which are
not bounces, the first word in the body, and possibly the Subject:
prefix, MUST be "NO".
ABNF:
negative-reply = fields CRLF %s"NO" CRLF msg-body
Both messages and replies MUST be duly authenticated by DKIM and
DMARC.
Negative replies are sent when the forwarder has no knowledge of the
agreement-id. That means the agreement was previously canceled,
never properly archived and in any case it is not active. After a
negative reply, the receiving domain can cancel the agreement without
further notice.
Replies which are not negative replies are positive acknowledgments
of the deal. Replies to cancellation and rejection have the same
effect whether positive or negative, and both sides can remove any
reference to the agreement afterwards.
8. IANA Considerations
Per [RFC8552], please add the following entry to the "Underscored and
Globally Scoped DNS Node Names" registry:
+---------+-------------------+-------------+
| RR Type | _NODE NAME | Reference |
+---------+-------------------+-------------+
| TXT | _fixforwarding | [This.I-D] |
+---------+-------------------+-------------+
Figure 1
Vesely Expires 11 January 2024 [Page 12]
Internet-Draft Fix Forwarding July 2023
9. Privacy Considerations
Forwarding agreements expose users' mailing list participation and
forwarded identities to their mailbox provider admins. That is
unavoidable. It has to be noted, though, that such knowledge can
hardly be kept secret from people who have access to all their mail.
Users need to trust their mailbox provider, and this protocol is not
the only reason why they have to. Still, in situations where the
forwarder wants to hide its forwarding from the receiving domain, it
SHOULD NOT request a forwarding agreement. Instead, rewriting bounce
address and From: header fields, besides bettering deliverability,
may also help hiding the true origin of messages.
10. Security Considerations
Maintaining per-user DMARC exemptions excludes gaming, especially for
domains that provide mailboxes to anonymous users. Domains that
restrict mailboxes to internal users can balance their knowing of the
user involved in an agreement request and the reputation of the
applicant to decide whether to trust the forwarder for all users
rather than just for the one at hand. The forwarder doesn't know
about this decision, albeit it may guess it by the speed
characterizing the acceptance of further agreements. This kind of
decision slightly simplifies DMARC filter settings, but not
agreements management.
Forwarders SHOULD verify DMARC and apply author domain policies
whenever possible. Especially mailing lists, unless they collect
posts from other mailing lists in turn, should reject messages from
domains who publish p=reject if authentication fails. Receiving
domains MUST NOT reject messages belonging to an accepted agreement
for DMARC policy reasons. DMARC Filtering MUST be applied by the
forwarder. Failure to do so SHOULD be reported to the forwarders
abuse address.
Forwarders MUST also apply content filtering. They MUST reject or
drop messages that the local content analysis filter determines to be
undesirable. MLMs that provide for moderation can treat dubious
messages that way. Alias forwarding may need to set the bar low
enough to avoid false positives, since it cannot resort to spam
folders or similar quarantine measures. The receiving domain MAY
reject or quarantine messages whose content doesn't meet its
policies, under its responsibility. While mailing lists exercise
some control on the quality of messages, aliases are completely
transparent. When bad messages belong to a forwarding agreement,
their quality is not to be ascribed the forwarder's reputation but
the author domain's.
Vesely Expires 11 January 2024 [Page 13]
Internet-Draft Fix Forwarding July 2023
11. Acknowledgments
The author whishes to thank Murray S. Kucherawy for reviewing the
draft and Stephen J. Turnbull for devising the method in Appendix A.
12. References
12.1. Normative References
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996,
<https://www.rfc-editor.org/info/rfc2045>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC2919] Chandhok, R. and G. Wenger, "List-Id: A Structured Field
and Namespace for the Identification of Mailing Lists",
RFC 2919, DOI 10.17487/RFC2919, March 2001,
<https://www.rfc-editor.org/info/rfc2919>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/info/rfc5234>.
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
DOI 10.17487/RFC5321, October 2008,
<https://www.rfc-editor.org/info/rfc5321>.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
DOI 10.17487/RFC5322, October 2008,
<https://www.rfc-editor.org/info/rfc5322>.
[RFC5782] Levine, J., "DNS Blacklists and Whitelists", RFC 5782,
DOI 10.17487/RFC5782, February 2010,
<https://www.rfc-editor.org/info/rfc5782>.
[RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
"DomainKeys Identified Mail (DKIM) Signatures", STD 76,
RFC 6376, DOI 10.17487/RFC6376, September 2011,
<https://www.rfc-editor.org/info/rfc6376>.
Vesely Expires 11 January 2024 [Page 14]
Internet-Draft Fix Forwarding July 2023
[RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based
Message Authentication, Reporting, and Conformance
(DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015,
<https://www.rfc-editor.org/info/rfc7489>.
[RFC7578] Masinter, L., "Returning Values from Forms: multipart/
form-data", RFC 7578, DOI 10.17487/RFC7578, July 2015,
<https://www.rfc-editor.org/info/rfc7578>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8552] Crocker, D., "Scoped Interpretation of DNS Resource
Records through "Underscored" Naming of Attribute Leaves",
BCP 222, RFC 8552, DOI 10.17487/RFC8552, March 2019,
<https://www.rfc-editor.org/info/rfc8552>.
[RFC8617] Andersen, K., Long, B., Ed., Blank, S., Ed., and M.
Kucherawy, Ed., "The Authenticated Received Chain (ARC)
Protocol", RFC 8617, DOI 10.17487/RFC8617, July 2019,
<https://www.rfc-editor.org/info/rfc8617>.
[RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Semantics", STD 97, RFC 9110,
DOI 10.17487/RFC9110, June 2022,
<https://www.rfc-editor.org/info/rfc9110>.
12.2. Informative References
[RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598,
DOI 10.17487/RFC5598, July 2009,
<https://www.rfc-editor.org/info/rfc5598>.
[RFC6377] Kucherawy, M., "DomainKeys Identified Mail (DKIM) and
Mailing Lists", BCP 167, RFC 6377, DOI 10.17487/RFC6377,
September 2011, <https://www.rfc-editor.org/info/rfc6377>.
[RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for
Authorizing Use of Domains in Email, Version 1", RFC 7208,
DOI 10.17487/RFC7208, April 2014,
<https://www.rfc-editor.org/info/rfc7208>.
Vesely Expires 11 January 2024 [Page 15]
Internet-Draft Fix Forwarding July 2023
[RFC7960] Martin, F., Ed., Lear, E., Ed., Draegen, T., Ed., Zwicky,
E., Ed., and K. Andersen, Ed., "Interoperability Issues
between Domain-based Message Authentication, Reporting,
and Conformance (DMARC) and Indirect Email Flows",
RFC 7960, DOI 10.17487/RFC7960, September 2016,
<https://www.rfc-editor.org/info/rfc7960>.
Appendix A. No-Munging Method
This protocol assumes that From: munging can be enabled or disabled
on a per-user basis. Many MLMs provide instead an option to enable
or disable it on a per-list basis. Here's a way to overcome this
limitation.
Have an umbrella list with two sibling sub-lists, one configured with
From: munging, the other one without. Both sub-lists refuse all
posts, and advertise the umbrella list as the destination for posts.
The umbrella list accepts posts according to site and list policy.
It has the sibling sub-lists as its only subscribers, and won't
accept more.
The sibling sub-list that does From: munging accepts subscribers
under the site and list policy. When forwarding agreements are
accepted, the relevant subscribers are moved to the other sub-list.
Author's Address
Alessandro Vesely
via L. Anelli 13
20122 Milano MI
Italy
Email: vesely@tana.it
Vesely Expires 11 January 2024 [Page 16]
