spf-discuss
[Top] [All Lists]

RE: Re: Bootstrapping trust model

2004-06-15 14:01:22
From: Frank Ellermann
Sent: Tuesday, June 15, 2004 7:10 AM


Seth Goodman wrote:

3) One user sends mail on behalf of another user - this is
even more rare, but is also in the RFC's.  In this case,
there is one From: address and one Sender: address.  The
Sender: address takes precedence
[...]
5) Other cranky people who insist on setting a different
address for bounces

Now wait, that's not too unusual, or at least I do it every
day.  My From: (see header) normally matches the Mail From,
when I use the smart host of my mail provider.  But this is
actually an ISP, and they only relay for me while I'm online
using this ISP.

For some private reasons (read: online costs ;-) I regularly
use another ISP on Sundays and from 9:00 to 18:00 on weekdays.
This 2nd mail provider does the right thing, they won't allow
me to forge the MAIL FROM, and therefore my mail is sent with
a "MAIL FROM my address at 2nd ISP" and a "From my address at
1st ISP".

This is an interesting scenario.  Thanks for bringing it up.


In theory I could add a Sender = 2nd address.  In practice my
MUA doesn't do this automatically.  In theory the MSA of the
2nd ISP could add a Sender = 2nd address.  In practice they
don't do it.  Therefore there's IMHO a case 5.a, where the
recipient could handle the missing Sender as if it would match
the obvious MAIL FROM (and continue with your case 3).

My email client (Outlook) is the same.  I can't send mail in someone else's
behalf.

Unfortunately, pretending it matches (or ignoring the mismatch) defeats any
anti-forgery benefits that requiring a match would have given.  How do we
tell a justified forgery from a malicious one?  We could flag the address as
untrusted, but content filters already do a very good job of separating real
communications from junk.  The main motivation behind my suggestion was as a
rejection criteria.  I do see that it would prevent you from using this
particular scheme.


Another possible solution for me would be to use my 2nd address
as From = MAIL FROM, and my primary address in a Reply-To.  But
this solution wouldn't work in some cases (mailing lists. old
software, etc.).  Therefore I'm quite happy with a (correct)
MAIL FROM for technical problems and an independent From for
normal replies.

I don't believe that's the case, but you'd have to try it to be sure.
AFAIK, mailing lists preserve From:, write their own address into Sender:,
Reply-To: and MAIL FROM:.  Some of them copy the From: into Reply-To: along
with the list address, which I find annoying.  I don't know about software
registrations, but I bet that they use From: rather than Reply-To:, which a
lot of people set to a different address.  Even though it is technically
forgery if you don't own the Reply-To: address, it is not practical today to
limit what people put in Reply-To:.  However From: could be handled
differently, since you authenticate yourself to the MSA and it _could_ force
you to use that as a From: address in exactly the same way your ISP #2
enforces what your MAIL FROM: is.  Perhaps as SPF becomes more popular,
ISP's would let you use a foreign MAIL FROM:/From: combination as long as it
was listed in an SPF record?

My argument in general is that SPF is about stopping 2821 forgeries, i.e.
MAIL FROM:.  Once SPF is widely deployed, people won't be able to forge MAIL
FROM: anymore, even in cases where it was for good reasons and not
malicious.  The "company line" concerning this for SPF is either: a) get
your provider to support SMTP AUTH over port 587 or b) get a domain and
designate your normal outgoing mailers in the SPF record.  Neither of those
aren't terrific answers, but it's what we have to give up to get SPF.  For
people without a domain and no access to SMTP AUTH, they are clearly
inconvenienced by SPF.  I think something similar may be required to stop
2822 forgery, particularly From: and Sender:.  Some people will be
inconvenienced.  The question becomes, is it worth it, considering the
potential benefits?

If you want a Sender matching the MAIL FROM
just pretend that it's there.

If we were to pretend it's there, why check for it at all?  We should decide
if it makes sense to use this test.  Yours is a case where this test would
definitely create an inconvenience.  You could use your first ISP on the
weekend, but that has financial considerations.  I guess there are a few
questions here.

1) How common is this scenario?

2) What other problems would this requirement cause?

3) Are there workarounds that acceptably mitigate the problems that strict
checking would create?  For example, for your particular problem, can you
convince your ISP #1 to support SMTP AUTH?  Another possible solution would
be a hosted email account that you could access through either ISP, with or
without your own domain.

4) The most important question: do the benefits derived from requiring
strict checking outweigh the problems created?


Really weird is IMHO Sender <> From <> MAIL FROM <> Sender, or
at least I don't see why this should be allowed.  But the case
MAIL FROM <> From and no Sender could be handled like case 3:
MAIL FROM <> From and Sender ~ MAIL FROM.


With the same loss of function.  Fortunately, this sounds like a somewhat
broken scenario.

--

Seth Goodman