From: Mark Shewmaker
Sent: Thursday, June 03, 2004 10:38 PM
On Thu, 2004-06-03 at 16:54, Ryan Malayter wrote:
Unless I'm missing something, a message with these properties:
ENVELOPE-SENDER: someguy(_at_)phisher(_dot_)com (no RFROM)
RFC-2822 From: Operations(_at_)FirstNationalBank(_dot_)com
RFC-2822 Sender: someguy(_at_)phisher(_dot_)com
will pass under the new SPF, assuming phisher.com has valid SPF records.
Everyone, stop the presses.
Ryan is right, and he has a good point.
Yes, he is right and it is important.
Background: Those of us who've been on the list for a while had
discussed this problem in regards to the previous SPF,
dismissing the problem as not being within the purview of
the old SPF.
I don't think anyone has brought it up since the merger.
(Though Seth recently brought up something very close.)
I did address this concern in a earlier post
<MHEGIFHMACFNNIMMBACAKEPHHPAA(_dot_)sethg(_at_)GoodmanAssociates(_dot_)com>.
My conclusion
there was that if Sender: and From: have different domains, we should
consider the From: as an untrusted address unless it is cryptographically
signed. More on that later.
<...>
Initial simplification:
-----------------------
<...>
So imagine an RFC2821-with-extensions MAIL command like so:
MAIL FROM:<SES-return-path(_at_)example(_dot_)com> \
SUBMITTER=<forwarder-account(_at_)example(_dot_)com> \
Sender=<sending-account(_at_)example(_dot_)com> \
OnBehalfOf=<me(_at_)example(_dot_)com>
A server receiving that line would do an SPF lookup on "example.com",
pull out some spiffy macro-laden validsenders= modifier, and use it to
see if me(_at_)example(_dot_)com allows
sending-account(_at_)example(_dot_)com to send mail on
its behalf!
This example is not forwarding as far as SPF is concerned because all the
addresses are in the same domain. Designated senders that can send mail on
your behalf (with your address in From:) is an interesting idea. I think
the rest of it may be overkill in that we really don't need to support and
authenticate four different addresses for real email applications.
First off, I would suggest that we require MAIL FROM: to be the same as
Sender:. RFC2821 suggests that when only 2822 headers are available, the
reverse-path should be constructed either from the machine name or the From:
header. The RFC also suggests that while MTA's may allow users to specify
arbitrary return-paths, this should be limited to administrators to reduce
forgeries (it really says that!). Therefore, I don't think it is such a
stretch to _require_ that MAIL FROM: be the same as Sender:, if it exists,
and From:, if there is no Sender:.
That gets rid of the Sender parameter. Sender is automatically validated
when we validate MAIL FROM: on the first hop. OnBehalfOf is really the
From: header and that's a sticky question. Does anyone outside the same
domain _really_ send mail in anyone else's behalf anymore, aside from
mailing lists? I can honestly say that I have never sent mail in someone
else's behalf and have never received a non-list message sent in someone
else's behalf. Someone will probably send me one now so that I can't make
that claim anymore :) The last time I had a secretary was about 20 years
ago and _she_ never even sent email on my behalf. She sent postal mail for
me all the time, but never email. This is purely anecdotal, but I believe
the facility is rarely used.
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.
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.
--
Seth Goodman