I'm thinking about RFROM, trying to figure out if there could be any
other uses for it or if there are other ways of accomplishing its goals.
(As an aside, I really do like RFROM in its current form--I'm not
wanting to be negative about it at all, but just to brainstorm a bit
around the edges of the idea.)
Variant 1: Multiple RFROMs
---------------------------
RFROM is sort of a layering violation, in that it allows you a "sneak
peak" at body headers before DATA, but of course that's very useful for
eventual 2821 type rejections and tests.
Given that it is probably going to be made into an official standard at
some point, I'm wondering what other use it or something very, very much
like it could have. (Continuing on the layering-violation thoughts.)
So, I'm back at the can-multiple-RFROMs-make sense question.
Imagine that RFROM wasn't a parameter to MAIL, but that it was a command
in and of itself, given after MAIL and before RCPT: Then you could have
multiple RFROM's for any message.
You would need one that would match the PRD. But, if you had additional
parameters, that could allow a syntax that could incorporate
accreditation-type claims such as:
RFROM <forwarding_account(_at_)example(_dot_)com>
RFROM <mailchecks(_at_)my_isp(_dot_)com> PUBCLAIM=is_spam=no,has_virus=no
RFROM <my_bank_account(_at_)my_bank(_dot_)com> PUBCLAIM=statement=yes
RFROM <my_bank_account(_at_)my_bank(_dot_)com>
PUBCLAIM=statement/overdraw_notice=yes
RFROM <vetted_by_my_accountant(_at_)myaccountant(_dot_)com>
PUBCLAIM=vetted=yes,tax_related=no signature_type=blah
signature=blah
RFROM <my_notary(_at_)notary(_dot_)com> PUBCLAIM=notarized
signature_type=blah
signature=blah
(I included signatures in the last two lines, but...if RFROM remained a
sneak-peak-at-body-data notion, then the signatures needn't be included
in RFROM, and could just be pulled from the data later.)
This does seem somewhat unwieldy, but ... I wonder if there is anything
useful along these lines?
(I'm fine with "nah, too complicated/should-be-done-in-other-ways types
of answers.)
Variant 2: BODYDATA extension instead/as-well
----------------------------------------------
The whole point of RFROM is to be able to see a specific bit of RFC2822
info, (the derived "PRD"), at RFC2821 time.
Until RFROM is implemented, receivers implementing SPF will have to look
at body data. After implementation, (after flag day), they'll only have
to look at body data to make sure the PRD matches after having done all
the other tests. But other related efforts, such as yahoo domainkeys,
will still have to look at body data for all their tests.
Folks have talked about a possible STMP extension to allow message body
headers to be transmitted before the rest of the message body. It
occurs to me that such an extension could overlap with an RFROM
extension.
Imagine a server with, say, a "BODYHEADER" extension, was expected to
accept or reject on the basis of BODYHEADER data per recipient, after
which it would accept or reject the rest of DATA, also per recipient.
(This is in contrast to the current inability of per-recipient post-DATA
rejects.)
So a connection to this MTA would receive commands in the order of:
EHLO
MAIL
RFROM
RCPT
BODYHEADER (return codes given for every recipient)
DATA (return codes given for every recipient)
If spf required both RFROM and bodyheader functionality after flag day,
that would mean that:
1. Mails for which RFROM does not match the PRD need not be rejected
for recipients that have SPF checking turned off. (Granted, it
might be a good idea to do that anyway, as such a mismatch implies
a corrupted email anyway.)
2. Other tests based on the message headers can be at least partially
done before all of DATA is received, without the need of yet
another extension giving sneak-peaks.
3. RFROM itself, and other similar future extensions, need not be
technically required for full functionality--they would instead
merely be more efficient.
4. ISPs could allow their users to select among many MTA-time body-
checking spam/virus tests, giving accepts or rejects per recipient
instead of globally. Currently any body-dependent checks must
either result in accept/reject globally for all users, or ISPs
must accept the email, then potentially filter/trash it for
some users (who so request that) after having claimed to have
"accepted" the email.
--
Mark Shewmaker
mark(_at_)primefactor(_dot_)com
770-933-3250