On Fri, 2004-06-04 at 08:53, Seth Goodman wrote:
What may be more useful is a modifier that says, "Reject any mail that
purports to be sent in my behalf, except for mailing lists that you trust".
That describes most people's situation and is the more important case. I
suppose if we have a sender modifier in SPF, we might as well allow it to be
populated with something in case you do have someone send mail in your
behalf.
But that is basically what I'm suggesting--with the exception that
mailing lists are handled in a slightly different way.
(ONBEHALFOF is a sneak peak of the RFC 2369 mailing list name in the
body headers, or From: if there is no mailing list name. That gives you
the same result as what you're wanting and also allows more
flexibility.)
However, I would still keep everything but originator and submitter out of
MAIL FROM: for brevity and compatibility with existing RFC's. By using the
deprecated reverse source route format of MAIL FROM:, we don't have to
modify any existing RFC's to do this. If the envelope SPF check passes, go
on to DATA and test everything else we can.
Two issues:
1. *If* we end up having a SUBMITTER variable, then I don't see why
something like SENDER and ONBEHALFOF can't be included in the
same defining RFC as well, (if those other variables are actually
useful.)
If SUBMITTER gets dropped for source- and return-routing, then
that's different. :-)
2. Because of the remaining, annoying
can't-reject-per-recipient-after-data limitation in SMTP, all
after-DATA tests have to be done for all recipients or none
at all. GRRRR.
(People will want to strangle me for saying this or wistfully
wanting this, but...it would be nice if somehow any
SUBMITTER-enabling rfc could require after-DATA per-recipient
accepts/rejects if SUBMITTER (or the other) variables were
used--That could help in the implementation and deployment of many
other later types of post-data checks.)
--
Mark Shewmaker
mark(_at_)primefactor(_dot_)com