RE: HELO vs. envelope checks

[Regarding SES in combination with localpart macros, exists:%{l}....]

--Seth Goodman <sethg(_at_)GoodmanAssociates(_dot_)com> wrote:
> 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.

Right... I am not on the SRS list so that's probably why I didn't see that 
before.

> 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.

Right... plus when combined with various macros you get a good idea of who 
is re-using your signed envelopes.

> > 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.

Right.  A forwarder is an agent for the receiver, and the receiver has to 
basically trust whatever they do, SRS or not.

> 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.

Actually, my point was that SES doesn't actually require CBV.  CBV shifts 
costs to the receiver.  SRS shifts costs to the forwarder (well, some 
costs)  SES plus %{l} macro shifts verification costs back to the sender.
Granted, it may be harder to record all SES envelopes, or create a DNS 
server that verifies SES local parts on the fly, but at least the sender 
assumes the cost.  And, it is still a DNS query, not a second TCP 
transaction.

> 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.

Right, storing the SES return addresses used becomes a problem, especially 
with multiple servers sending.  The key to making it feasible would be a 
DNS server that answers Yes for valid signatures and No for invalid ones 
without recording the whole history.  But, if we can build a rate-limiting 
DNS server, we can probably build a signature-verifying server as well.

> 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.

Agreed.  Similarly the exists:%{l} query would not be needed if a: or mx: 
are met.

> 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.

Right, there are similarities between SPF+CBV and SPF+SES+%{l}... SES+%{l} 
is probably a little harder to set up but once it is done you have normal 
SPF DNS queries and no CBV would be needed.

> 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.

Right!  I think we are on the same wavelength (or at least a similar one :)

I still believe that SRS is the right way to go for most bulk forwarders. 
Some senders could still screw with forwarders by writing -all anyway.  The 
nice thing about SES is that the verification methods that work on SES also 
work on SRS the same way.  So, my thought is that early adopters might like 
SES as an alternative to ?all or -all, and to control bounces received from 
non-SPF sites, but that eventually the forwarders need to take 
responsibility for their own return paths anyway.
--
Greg Connor <gconnor(_at_)nekodojo(_dot_)org>