From: (no name) (no email)
Date: Sat Jan 10 2004 - 11:35:11 EST
On Sat, 10 Jan 2004, Wietse Venema wrote:
> That would be too late. The SMTP server must know whether an RCPT
> TO or MAIL FROM presents a valid address before accepting the mail.
>
Also the counter in the cookie cannot reasonably scale to more than one MX
host without introducing unreasonable requirements for centralized
storage.
1. I am not likely to either implement SPF or say that SPF is a good idea
any time soon.
2. This said, the question of *when* to perform SPF rewriting if such
rewriting were to be done wisely or otherwise can be made clearer:
- SRS Rewriting is only performed when the recipient address is
changed in transit through the current host. So backup MX hosts
do no rewriting, they are not forwarders, they are relays.
- Also gateway systems do no rewriting, even when they do rewrite
the envelope recipient, when they perform gatewaying for the
destination system.
- Virtual alias domains may have recipients in related domains
behind a gateway (corporate deployment) or recipients in
unaffiliated domains (ISP deployment). Postfix would have to
distinguish between the two cases, presumably the "smtp"
transport would SPF, and the "relay" transport would not.
- SRS Rewriting is only performed when the original sender is
intended to receive bounces, no such rewriting is required for
mailing list submissions. Rewriting is required for alias
expansions lacking a local "owner-" alias.
- Hosts may not apply SPF restrictions when receiving mail from
backup MX hosts or gateways associated with their organization.
Only mail originating from suitably defined external systems
that is again to be forwarded needs SRS sender rewriting.
...
The implementation logic in the delivery agent would be something along
the lines of:
if (strcmp(rcpt, orcpt) != 0 /* Potential forwarding */
&& var_srs_rewriting /* Yes in "smtp" no in "relay" */
&& is_spf_domain(sender) /* Domain is not ours and does SPF */
&& !trusted_origin(origin) /* Did message orinate from "outside" */
&& .. more conditions? ...)
{
srs_sender = srs_rewrite(sender);
}
The trusted_origin() test needs to be performed accurately and is hard to
get right. The SPF domain status lookup may fail, so one would have to
defer the message until the sender domain status can be verified. Saving
this in the queue file when the message is accepted can be wrong, because
the message can be in the queue a long time, and the domain SPF records
may change in the mean-time, so the status likely needs to be looked
during delivery.
Wietse's point about egress sender validation applies, since
bounce+remote+cookie at mydomain
cannot be easily checked on egress. And of course on ingress the
bounce+remote+cookie at mydomain address would need to be checked in the SMTP
daemon (another policy server).
Growth in the sender address along the forwarding path can get quite
unreasonable, but once all the sites along the path use SRS cookies the
address cannot be trimmed without saving state and introducing a central
data store for cooperating MX hosts. If there was a *standard* SRS
encoding acceptable to all, one could save just the previous hop's cookie,
this is not likely to happen any time soon and imposes unreasonable
constraints on the structure of the *local* part of the address whose
semantics have always been *local*.
If I were to bet money on the likelihood of widespread interoperable
robust SPF/SRS adoption within the next 5 years, I would bet against it
even at unfavourable odds...
-- Viktor.
|
|
|