Subject: Re: [Asrg] Re: This is a request for feedback from experts/regulars to help reduce spam backscatter from Sieve implementations

From: "David Nicol" <[email-masked]>
Date: Fri, 1 Dec 2006 15:19:05 -0600

On 11/30/06, Frank Ellermann <[email-masked]> wrote:

> It's no illusion, it's the definition, and senders know that it can't
> work reliably (if at all) if SPF is checked behind the border-MX.

As I understand it:

receivers that do SPF checks past the border are broken.  Repair
options include (1) special-casing border machines (2) doing SRS
forwarding from the border instead of plain forwarding.

Given the SPF point of view, non-SRS forwarding is broken and
should be replaced with SRS forwarding.  That is part of the
SPF adoption block.

-- 
perl -le'1while(1x++$_)=~/^(11+)\1+$/||print'

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Mark <[email-masked]>
Date: Sat, 02 Dec 2006 00:35:57 GMT

> -----Original Message-----
> From: David Nicol [mailto:[email-masked]] 
> Sent: vrijdag 1 december 2006 22:24
> Cc: [email-masked]
> Subject: Re: [Asrg] Re: This is a request for feedback from 
> experts/regularsto help reduce spam backscatter from Sieve 
> implementations
> 
> 
> > It's no illusion, it's the definition, and senders know
> > that it can't work reliably (if at all) if SPF is checked
> > behind the border-MX.
>
> As I understand it:
>
> receivers that do SPF checks past the border are broken.

Yes. Which is to say, receivers who do SPF checks on the envelope-from /
HELO, using the connecting IP address of anything that does not belong
to the client at the border MTA, are broken.

> Repair options include (1) special-casing border machines
> (2) doing SRS forwarding from the border instead of
> plain forwarding.

SRS really is meant more for "outgoing" connections (into the real world).
It seems kinda silly, IMHO, to do SRS rewriting towards any of the
machines in your network past the border. Those machines should simply not
be doing SPF-checks. Or, if they do, like, say, a machine with
SpamAssassin on it, with Mail::SpamAssassin::Plugin::SPF running, they can
use the info of the connecting client (from the border) in the
Received headers added by their own, trusted network.

Otherwise, doing SRS towards your own network just means you're getting a
continual "pass" for nothing else but the domain of your own border MTA.
At which point, hopefully, the futility of doing so kicks in. :)

- Mark

---

From: "David Nicol" <[email-masked]>
Date: Fri, 1 Dec 2006 23:58:45 -0600

> At which point, hopefully, the futility of doing so kicks in. :)

I won't argue if you call me sloppy.  I meant using SRS as a way to encode
the info from the border, so that the SRS would need to get decoded before
a later check, if possible.  In a complex border situation with machines with
multiple roles receiving from both their border peers and the outside, there
would be a bunch of edge cases. I'm really making this up as I go here.

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 02 Dec 2006 17:22:39 +0100

> receivers that do SPF checks past the border are broken.

In theory receivers can determine their own border (with an MX query),
and identify the corresponding timestamp line (Received: header field).

There they'll find the connecting IP and HELO, and can check SPF for
an already accepted mail.  SpamAssassin can apparently get this right,
and (in theory) SpamCop's default parser also uses this strategy.

SpamCop's "mailhosts" parser can handle forwarding scenarios, where a
simple MX query won't work.  In practice SpamCop doesn't use SPF to
identify forged Return-Paths, because the submitter already said that
it's spam, a forged Return-Path or not is irrelevant for SC.

With SA's approach, if used after the mail was already accepted, SA
could still create a Received-SPF header.  I can't tell if SA actually
does this, or if it just transform it into a configurable score.  For
SIEVE the situation is in essence the same as for SA.

It's not really "broken" to check SPF too late, it's only hard to get
it right, and it's not more possible to reject a FAIL.

Another scenario are SPF HELO-checks, they work everywhere, not only
at the border.  Combined with a white-list of known HELOs you can use
SPF to check the HELO everywhere, and skip the MAIL FROM checks for a
HELO PASS of a known "good" sender.  With that approach the MXs could
always check HELO, forward mails between themselves, and skip further
MAIL FROM checks for mails already checked at the border.

But generally, without tricks and talking only about MAIL FROM, it's
as you say "broken" to check SPF behind the border.

> Repair options include (1) special-casing border machines (2) doing
> SRS forwarding from the border instead of plain forwarding.

See Mark' reply, you won't do SRS for any forwarding within the "MRN"
(mail receiving network), e.g. if a backup MX moves its stuff to the
primary MX, or to the MDA, or however that's organized internally.

For a definition of "internal" including outsourced MXs, not limited
to the same "ADMD" in Dave's terminology, but limited to the same MRN
in Keith's terminology.

Frank