spf-discuss
[Top] [All Lists]

RE: HELO vs. envelope checks

2004-05-17 12:46:41
From: Greg Connor
Sent: Monday, May 17, 2004 1:10 AM


On Thu, 6 May 2004, Tony Finch wrote:

I would like to be able to say in SPF for my mail domains
(e.g. cam.ac.uk):

(HELO) No machine may legitimately use this domain as a HELO argument.

(ENV) All sender addresses in this domain are signed and do not have to
come directly from one of my MTA addresses. [There is a LOT of
forwarding
in my environment and I cannot break it.]



<...>

As for accepting only signed return addresses, that could
probably be done
with local part checking as well but it's a little harder.  One
idea would be
to log all the SES addresses for outgoing mail, and add them to
the DNS as
valid localparts for a short time.  The more elegant solution
would be to use
a custom DNS server that is capable of verifying the signature
and returning
IN A 127.0.0.1 for the ones that check out.
   v=spf1 a mx +exists:%{l}.oksenders.%{d} -all
In that case the localpart should be acceptable no matter what
mailserver has
passed the message... but a crafty forger could find a message
FROM you and
copy the SES part to send more mail apparently from you.
Probably this would
be best used in conjunction with rate limiting and timeout so
that the same
SES could be checked 5-7 times and then invalidated or something.
 (As a side
effect you also have queries coming in to help you track where
the mail is
going, if you bother to log them)

I wonder... have we inadvertenly hit on something that might address
forwarding without requiring the middle agent to use SRS?

This is what a number of us have been pointing out for quite a while,
thought the mechanism for doing SES hasn't, as yet, been DNS.  And as you
correctly surmise, you can send signed SES mail from anywhere, as long as
the MSA is willing to validate the SES signature with the domain MX for the
claimed return-path before accepting the message.

As for the susceptibility to replay attacks, we have been discussing that
for a while in SRS-discuss.  I think that this is limited to a small number
of promiscuous sending accounts and there are several possible solutions to
it for those cases.  As such, this susceptibility is a bit overblown as it
is not a problem for the majority of email senders.


The combination of
SES and %{l} is not as foolproof as actually checking the IP, and
you would
need a rather specialized DNS server to understand SES and rate
limiting...
but it is possible to construct a signing system with SES and
SPF, and that
would create a solution that puts the cost burden on the sender, not the
forwarder.  Something to think about, anyway... perhaps it would
make a good
interim solution for some sites that don't want to wait for forwarders to
become SRS-compliant.

I think a combination system would do better than that.  With SRS, you can
only have confidence in the ability of the forwarder to send mail on behalf
of the forwarding domain.  Since the forwarder may or may not have done an
SPF check on the incoming mail (for example, the domain was whitelisted),
and since they may have acted on the result differently than you would (for
example, accept softfail and unknown rather than reject), you have no
reliable information as to the credentials of the originating site to use
the claimed return-path.  This defeats one of the key original goals of SPF:
to give the recipient a tool to determine whether the return path is forged.

Let's consider the broad picture for a moment.  Some people object to SES
because it requires a CBV, which is a TCP transaction and thus more
expensive than a UDP DNS query.  On the other hand, a number of services,
both large and small, already do CBV's and find it cost effective.  While a
CBV is more expensive than a single DNS query,  evaluating an SPF record
often result in multiple DNS queries, so the actual cost differential is
reduced.

Putting all timestamped sending addresses into the DNS for a domain is a
really interesting idea.  However, you're talking about adding and expiring
_lots_ of addresses every day into a domain's DNS.  Not being a DNS guru, I
don't know about the implications of this, but it does sound complicated.
I'm willing to be educated on the matter.

Many, if not most, email transactions take place without a forwarder in the
loop.  That is, they are originating gateway MTA to destination gateway MTA
direct connections.  As the SMTP-server for the destination gateway MTA, if
we knew that the SMTP-client was a designated sender for the return-path
domain, there would be no need to do a CBV since we are talking to the
originating gateway MTA or one of its secondaries.  This would avoid the
majority of CBV's currently required by SES.

Based on the above, let me propose the following hybrid system of SES+SPF
that I believe accomplishes all the original SPF goals and does not require
SRS.  It doesn't put all the SES information in the DNS, so it still uses
CBV's, but it performs many fewer CBV's than pure SES.  I assume in the
following that the SMTP-server has already done all the IP and HELO based
heuristics that it cares to and the SMTP-client has not failed any tests.
It also assumes that no messages are SRS rewritten.  We can easily modify
this for SRS rewritten messages, but I believe this particular combination
makes SRS unnecessary.  To highlight the basic mechanism, I've left out any
measures to foil replay attacks for those few accounts that require it.
These can be easily added.

1) The SMTP-server performs an SPF check on the MAIL FROM: domain with
respect to the SMTP-client.  If the SPF result is PASS, the SMTP-client
SHOULD consider the return-path validated and stop here.  [Note: an SPF
result of PASS, in the absence of SRS rewriting, indicates that the
SMTP-client is the originating gateway MTA for the return-path domain.]  If
the SPF result is UNKNOWN, SOFTFAIL or NEUTRAL, the SMTP-client SHOULD
consider the return-path suspect and proceed to the next step.

2) The SMTP-server examines the return-path address for an SES signature.
If present, the SMTP-server does a CBV to the MX for the return-path domain
to validate the return path (the SMTP-server is now an SMTP-client for the
CBV).  The SMTP-client then terminates the CBV session.  If the CBV result
is a 250, the SMTP-client SHOULD consider the return-path validated.  If the
return-path does not contain an SES signature, the return-path cannot be
validated and the SMTP-server action is left up to local policy.


For an originating gateway MTA to destination gateway MTA direct SMTP
transfer, the return path is validated with SPF alone.  With a single
forwarder in the loop, the forwarder validates the originating gateway MTA
using SPF alone.  The destination gateway MTA does an SPF check on the
forwarder that fails, and then does a CBV to the return-path domain MX to
validate the return path.  Subsequent forwarders generate one additional CBV
to the return-path domain MX per forward.  In no case is a forwarder the
target of a CBV for forwarded messages.

This scheme also allows people to send out mail from foreign MTA's, as long
as they can create a legitimate SES-signed return path.  The foreign MSA can
first check the return-path domain against blacklists, then validate the
return-path with a CBV to the domain MX before accepting the message.  Since
SMTP AUTH is a TCP process, it is arguable that when not on the home
network, submitting mail via local network to a foreign MSA and having that
MSA do a CBV to validate it requires less internet bandwidth.

Thanks for a suggesting one way to combine SPF and SES.  Though what I have
above is somewhat different from what you suggested, I think that combining
SPF and SES is ultimately a sound approach that can obviate the need for
SRS.  It also gives the final recipient much higher confidence in the
return-path, which is what this is all about.

--

Seth Goodman