RE: Re: New ideas for RFC2822 headers checking with SPF
2004-10-23 18:53:05
--Seth Goodman <sethg(_at_)GoodmanAssociates(_dot_)com> wrote:
a) MSA immediately rejects, with explantation, any message where the
highest of From:/Sender:/(newest)Resent-From: does not match return-path.
This would be ideal, though I don't know if all MUA's can set return-path
properly. This approach avoids all ethical and legal problems. If the
explanation returned included web links to clear instructions on how to
correct the setup in each of the common MUA's, service calls would be
reduced, but not eliminated.
I would suggest modifying this to say "rejects any message where the
domain of the most recent From:/Sender:/(newest)Resent-From: does not
match the domain of the return path." Adding "domain of" allows things
like SES/SRS or VERP to work.
Some people will want to send mail as domain.com but have bounces go to
return.domain.com or bounces.domain.com or something. I'm not sure how to
accomodate those.
b) MSA enforces equivalence by changing/adding headers according to the
following rules: if return-path is different from the authenticated
identity or missing, set return-path to the authenticated identity; if
From: is different from the authenticated identity and there is no
sender, add Sender: with the authenticated identity; if Sender: is
different from the authenticated identity and there is no Resent-From:,
change Sender: to Original-Sender: and add Sender: with the authenticated
identity; if newest Resent-From: is different from the authenticated
identity, change Resent-From to Original-Resent-From: and add
Resent-From: with the authenticated identity. This approach will
generate few if any service calls (only very knowledgeable users would
even notice this), but is perhaps on shaky legal footing. Perhaps one of
the attorney's on the list could comment? I wouldn't like my mail
tampered with this way, but I'm not an average user.
I would prefer to have messages rejected rather than modified. RFC2476
allows us to reject a message if we can't associate the return path with
the actual user. I don't know if it gives us the power to change it...
c) MSA's for hotel rooms/greeting card sites are in a somewhat different
position. They have no ability to validate that the user has the right to
use any particular address. A reasonable approach for them is to act the
same way as a mailing list: preserve the From:, add their own address
both for Sender: and return-path. The site sending the message has to
take responsibility for it. Just as what mailing lists should but often
don't do, if there is already a Sender: or Resent-From: header, the MSA
should change that to Original-Sender: or Original-Resent-From: and put
their own address in Sender: or Resent-From:.
That is sensible.
2) Recipients would read the sender's SPF record, and if there is a
2821=2822 header equivalence statement, would check the 2822 headers for
equivalence during the SMTP transaction. If they did not match, the
recipient could do one of two things, depending on local policy:
a) Reject the message at the end of data with an appropriate 5xx error
message. This is respecting the sender's anti-forgery policy.
b) If the message is otherwise acceptable, add an SPF header that includes
the fact that the 2821 and 2822 headers should have agreed, according to
the sender, but didn't. In this case, it's up to the MUA and user to
sort it out, which is why I don't like this solution. Since the SPF
header is a trace header, I see no ethical or legal issues with it.
I'm still not excited about evaluating some headers "by association" to
other headers, but I am feeling like I'm in the minority :)
I think the reason I would prefer to evaluate headers one at a time and not
in combination is based on the idea that if I trust a server enough to
place it in my SPF record, I should be able to trust that server to use my
domain name *correctly*. If I want to use my domain name as a return
address, but only when the From: address matches, I can arrange this with
my service provider. I don't need to burden the receiver with checking all
manner of compliance -- either the server doing the sending is authorized
to use my name (in whatever context) or not. In other words, I don't want
to require additional complexity on the part of the receiver for something
that the sender should really be checking.
> the world is moving in the direction of requiring the at
> least the 2821 and 2822 domains to be the same. Eventually,
> it may get more strict.
Some years ago the world was apparently moving in the direction
of using PGP or S/MIME everywhere. Let's see what happens.
I can't argue with the failure of that prediction, but I didn't make that
one :) The reason for the world moving in the direction of 2821 and 2822
identities being the same is that there is no other relatively simple way
to stop this important type of forgery. I've seen proposals that each of
the identities would be validated separately. That is low overhead only
if the validation mechanism is designated sending IP, and that only works
on the first hop. Though people can dismiss forwarding as a minor part
of mail traffic, if the authentication means for these various identities
work on the first hop only, you can be sure that spam will move for mock
forwarding to get around it.
For an authentication mechanism to be worth anything, it has to work
end-to-end. In that scenario, it does not make sense to validate the
identities separately, unless each includes strong crypto that signs
message content to avoid replay. That puts an unacceptably high burden on
recipients, IMHO. As a recipient, I don't want to validate six different
public key signatures before I can reject a forgery.
Let's go back to basics. An MUA authenticates itself to an MSA and then
submits a message to the MSA. The MSA has an authenticated identity for
the MUA and a message submitted by the MUA. That is the obvious place to
prevent forgery, using whatever method is ethical/legal for the MSA. This
will vary from locale to locale, but the bottom line is that the MSA is in
the best position to prevent forgery since the MUA has to authenticate to
it. So what constitutes forgery? Perhaps this is the key to the
discussion and where people might disagree. Here's my definition: using
an identity that the MUA does not have the right to use.
That doesn't mean that the identities have to be the same, but that the
MSA has to be able to ascertain that the MUA has the rights to any
identity that it claims. Obviously, the MSA knows that the MUA has the
rights to use the identity that authenticated with. Beyond that, it gets
complicated. There is no technical reason why we couldn't build a system
where the MSA can verify the MUA's right to use alternate identities.
I think a good policy for ISPs would be
1. authenticate the user with SMTP AUTH (or some other method, pop before
smtp, association with the IP issued to them by DHCP, whatever, as long as
it reliably validates the user identity)
2. Allow them to use their isp-issued address, or any address in a domain
that they own, if the ISP manages the domain for them also.
3. Allow them to use other return addresses, if they are on the user's
"other address list". This means they should confirm by email that they
are really the owners of that address (similar to how mailing list servers
validate your address)
... Since it is opt-in, in
doesn't break anything that doesn't participate. However, I do predict,
for all of the reasons above, that this will gradually become the
expected practice. Perhaps a system that allows MSA to validate an MUA's
right to use a foreign address will come to pass. That would be optimal,
but I doubt that will happen. Requiring equivalence is a 90% solution to
the problem that requires a fraction of the effort of the 100% solution,
so that is the basis for my prediction that the two identities will
_eventually_ be expected to match for good delivery rates.
I hope MSAs will start to move in this direction. The brute-force method
would be to only allow the equivalent address, or addresses that the ISP
knows for sure that the user really owns.
I don't think expanding SPF to make it establish relationships between
multiple domains across multiple headers will make more ISPs do the right
thing with their MSAs. I think the real solution is for ISPs to get off
their asses and conform to RFC 2476 ;)
I read the rest of the message but didn't reply to the remaining points,
because they have to do with requiring equivalence between two headers. I
think that if you can support the checking of From: or Sender: type of
headers at all, checking them on their own would cover most of the cases
you want to check for, and linking multiple headers together would
introduce more complexity and little added value. In the context of
MSA/MUA, this is probably even more true -- if you claim that you trust
your ISP, you can work out with them whether they use your domain name
appropriately without the use of SPF.
--
Greg Connor <gconnor(_at_)nekodojo(_dot_)org>
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- Re: New ideas for RFC2822 headers checking with SPF, (continued)
- RE: Re: New ideas for RFC2822 headers checking with SPF, Seth Goodman
- RE: Re: New ideas for RFC2822 headers checking with SPF,
Greg Connor <=
- RE: Re: New ideas for RFC2822 headers checking with SPF, Ralf Doeblitz
- RE: Re: New ideas for RFC2822 headers checking with SPF, Greg Connor
- RE: Re: New ideas for RFC2822 headers checking with SPF, Scott Kitterman
- RE: Re: New ideas for RFC2822 headers checking with SPF, Greg Connor
- RE: Re: New ideas for RFC2822 headers checking with SPF, Seth Goodman
- Re: Re: New ideas for RFC2822 headers checking with SPF, Chris Haynes
- Re: Re: New ideas for RFC2822 headers checking with SPF, william(at)elan.net
- RE: Re: New ideas for RFC2822 headers checking with SPF, Scott Kitterman
- RE: Re: New ideas for RFC2822 headers checking with SPF, Seth Goodman
- Re: New ideas for RFC2822 headers checking with SPF, Frank Ellermann
|
|
|