Frank Ellermann writes:
Dick St.Peters wrote:
In 5.3.6(a) alias forwarding, the return code is 250, not
251.
Without checking, 1123 didn't chage the return codes. The
interestig case for SPF is "user not local", other aliases
within the same organization (no 3rd party MX involved)
have no potential problem with SPF.
For that "interesting case", the return code is still 250 unless you
want the sender to send future mail to a different address. The
difference between 250 and 251 isn't where the user is, it's where the
sender should send future mail.
From a 821-POV forwarding to 3rd parties was a temporary
courtesy / hack, not a permanent solution.
821 happens not to describe permanent alias forwarding, but it was
already in common when 821 was written. 821 does allude to it when
saying that the distinction between an alias and a mailing list with
one entry is "fuzzy".
Anyway, an 821 POV is frequently not very relevant to today's mail.
For example, what we now regard as the destination address was a
"forward-path" in 821 terminology. Mail frequently was forwarded from
host to host, and senders not only needed to know the path to the
intended recipient, they needed to specify it when sending mail.
These source routes enshrined by 821 have been deprecated since 1123,
and nobody calls the MAIL TO address a forward-path anymore.
To put alias forwarding in an immediately relevant context, somebody
is going to be webmaster(_at_)openspf(_dot_)org, and it won't be the same person
forever. If someone sends mail to that address, you don't want them
getting a 251 telling them they should have sent the mail to the
current webmaster's everyday address. You do want the mail forwarded
(assuming it's legitimate) to the current webmaster, who may be
anywhere on the planet.
But the effect of SPF FAIL caused by 251-forwarding
is like 551, if neither forwarder nor next hop did
anything about it. A simple solution is 5.3.6(b) -
behave like a mailing list.
Not quite like a 5.3.6(b) mailing list. For a mailing list, bounces
go to the list owner; senders don't get (and seldom want) notification
that a given list member didn't get their mail. For alias forwarding
to a one-address alias, senders need to be notified if their mail
doesn't get through - bounces must be forwarded back to senders.
A non-simple solution is SRS, where bounces come back to the forwarder
addressed to the SRS address. From the bounce address the forwarder
first can verify that the bounce is genuine (is a bounce of mail that
was in fact forwarded). Then the forwarder can determine to whom the
bounce should be forwarded.
--
Dick St.Peters, stpeters(_at_)NetHeaven(_dot_)com