On Wed, 2004-06-09 at 07:45, Stuart D. Gathman wrote:
On Wed, 9 Jun 2004, Mark Shewmaker wrote:
The only fly in the ointment is getting all SPF receiver implementations
upgraded.
True.
To get the same result with current SPF1 (albeit uglier and less efficient),
you can use multiple exists queries.
I believe you'd have to write a single, very complex, difficult-to-parse
exist _mechanism_, (ie, "exists:blah") so the whole shebang can pass or
fail at one go.
That also complicates the DNS server work on the sending side. (And it
makes it more difficult to outsource things like SES verification to
other DNS providers.)
I'd like to be able to write multiple, smaller, exists _modifiers_
("exists=blah"), which I can visually check the correctness of when
publishing, and can mostly even implement with static DNS records. (No
intelligent DNS programming needed for statements like "these three
users permit these five senders, and all other users permit no others as
senders, as I'd have default wildcards for most users, and then actual
records for others. This is a small amount of work, and uncoupled from
work related to any other exists= modifier, especially compared to
having to keep up with all combinations of that test and PRA tests and
any others, all in one long queried string.)
In any event, it looks to me like all the advantages of the new spf
could exist (haha) in old-spf world using an exists modifier and extra
macro variables.
Even in a new-spf world, the permitted-senders concept can work, *if*
there's an exists modifier and extra macro variables.
Yes, the the idea of caching key "after DATA" variables before DATA
and verifying them later is a good one. But it requires enhancing
ESMTP to provide the additional MAIL FROM parameters as well as
adding more macros to SPF1. When either MTA doesn't support the
new ESMTP parameters, the value of the new SPF macros will be unavailable.
Nope--just fall back to waiting until after DATA if the info isn't
available before DATA.
While this doesn't work with the new SPF as currently defined, (since
after flag day the PRA is assumed to be the MAIL FROM parameter if
there's no SUBMITTER), it can work just fine with the old SPF if it were
to have exists= modifiers and the extra macro variables.
(It could also work with the new SPF if the spec were tweaked to
accommodate it, ie, don't do any pre-DATA tests on SUBMITTER unless it's
there but...then we might as well just do the old SPF and tweak it with
exists= and extra macro variables.)
So this enhanced system will need to handle optional macros.
It will be a while before all this is in place.
We'd have to wait for SPF receiver implementation changes, yes.
But not for official ESMTP parameters.
The spec could have very clear rules about any "exists=" modifier that
contained references to 2822-based variables, since at any given time,
SMTP extensions might exist to give a sneak-peek of any particular
2822-based macro variable, and there's no need to have to update the SPF
spec about that.
One concise set of rules could be:
1. Evaluate "exists=" modifiers as far as can be evaluated
based on before-DATA SMTP info, including any
sneak-peak SMTP extensions used by the sender, (which
would naturally also mean the receiver understands
the extensions.)
2. After DATA, check that all the sneak-peak variables
actually matched what would be found by looking at the
message contents itself. Return FAIL if any don't match.
(This would mean that the message is corrupt, or the sending
MTA lied. It's the same as new-spf's FAILing messages where
SUBMITTER!=PRA.)
4. After DATA, run any remaining "exists=" tests that
require variables not found in sneak-peak extensions.
5. Shortcut: If at any point, any processed exists=
modifier returns FAIL, stop all processing and produce
a final result as FAIL.
This means that all these sorts of tests could be done without SMTP
extensions, (though could be done more efficiently if/once sneak-peek
SMTP extensions go through), could be disabled by anyone who objects to
all after-DATA checks for religious reasons, and best of all--requires
no flag day.
As individual tests become more popular or SMTP extensions become
available, it becomes more and more in everyone's best interest to
support the extensions and tests.
It's a win-win all around:
o Everyone has advantages in publishing data, even if only a minority
uses the published data.
o Everyone has advantages in implementing SMTP sneak-peak extensions
outward, in whatever form.
o All those doing the tests have advantages in implementing
SMTP sneak-peak extensions inbound, in whatever form.
o And if you object to all after-DATA checks, just don't
execute exists= macros containing data only available
in 2822 headers. It's not the same as skipping a mechanism.
You're merely skipping "other reasons" why the message might
be forged.
--
Mark Shewmaker
mark(_at_)primefactor(_dot_)com