On Mon, 2004-05-10 at 12:07, Meng Weng Wong wrote:
| Is there an major reason why SPF can not use the helo/ehlo domain as a
| primary reference rather than as a fall-back? The SPF proposal should
| consider an immediate benefit of using DNS to authorize the MTA long
| before repudiating mail 'from' becomes practical.
Sounds to me like two sides of the same coin.
If HELO is allowed to bypass mail-from repudiation, gaming becomes
trivial and the adoption dynamic is weakened. From my observations,
more people are interested in stopping joe-jobs than in asserting the
validity of their MTA as with the SS/MTAMark/.mxout./CSV family of
proposals. So we should continue to focus on this line of work.
| From my understanding, the first task of this work group is to
| consider authorizing the MTA and not repudiating mail 'from'.
Considering that the spiritual ancestor of all the LMAP proposals was
Vixie's "Repudiating Mail-From", it looks like there is generally more
interest in the 2821.mail-from as a primary identity ahead of HELO.
'Repudiating MAIL FROM' was proposed two years ago. The 2821 'from'
header defines a mailbox as a return path. A decision process to report
errors or discern if this return path is valid is different from a
process accepting an MTA connection. A process to accept the MTA
connection should be step one in any repudiation process. If the MTA is
detected as not offering a valid domain name via the helo/ehlo response,
no further checks are required as the connection may be safely refused.
Making this a required step for qualifying mail does not detract from
checks on the return path.
Establishing MTA validity check as common practice may be put in place
much sooner than being able to reject individual mail based on return
path conflicts. Even 'Repudiating MAIL FROM' indicated other changes,
in addition to establishing DNS records for outbound SMTP servers, is
needed before rejecting mail based on the 'from' criteria becomes
practical. These issues will require significant changes yet to be
defined. As example, many ISP intercept SMTP connections unbeknownst to
the client. Problems with lists servers and forwarded mail also become
problems to impair adoption of stringent reverse path checks.
Putting notices on mail as not verified being sent from a valid MTA
should be part of a transitional phase-in leading to reliance on the DNS
information based exclusively on the helo/ehlo domain information. Once
this check is in place, further checks can be added. These checks may
use the helo/ehlo domain rather than IP addresses as a means of
expanding authority. Currently there is no limit on the recursive depth
of the SPF standard as you have proposed.
An ISP provider could offer a helo/ehlo domain to clients on a
provisional basis requiring adherence to acceptable use policies. This
would allow consolidation of the SMTP name space such that a reverse
path could be managed and thus verified. It may not be practical for
every domain to list all possible IP addresses used by SMTP on their
behalf. This becomes more practical if there is consolidation of this
name space used to publish this information. If headers are modified to
bridge over areas of unpublished relationships, then trusting the MTA
making these modifications is critical. Validating the MTA makes good
sense as a first step.
MTA validation does not detract from checking the return path. The DNS
records should be compatible of course and SPF makes a good starting
point. In addition, there could be information related to processes
offered by the MTA published as an aspect of the helo/ehlo domain. The
return path domain is unrelated to disparate processes that may happen
at each node. Step 1) check the MTA helo/ehlo domain, step 2) check the
return path.
-Doug