spf-discuss
[Top] [All Lists]

Re: post-SRS SMTP extension for anti-spam tools/methods

2004-02-15 18:04:57
On Sun, Feb 15, 2004 at 10:54:47PM +0100, Za'mbori, Zolta'n wrote:

My idea is two additional MAIL command:

MAIL SNDR:<initial-envelope-sender-address>
MAIL FROM:<current-sender-address>
MAIL RTRN:<envelope-return-address>

SNDR is the mailbox address of the message submitter,

FROM is the mailbox address of the message forwarder, or
the domain name of the message relay (in form: 'AT domain'),

RTRN is the envelope return path.

What do You think?

I think:  "How confusing: 'SNDR' is not sender; why not 'ORIGIN' or 'AUTHOR'"
And also: "How is this going to protect us?"

connection coming from host "mailhost.openrelay.tld" with DNS:
  openrelay.tld           TXT  "v=spf1 MX -all"
  openrelay.tld           MX   mailhost.openrelay.tld.
  mailhost.openrelay.tld  A    1.2.3.4
  4.3.2.1.in-addr.arpa    PTR  mailhost.openrelay.tld.

mail session:
  MAIL SNDR:<innocent(_dot_)victim(_at_)example(_dot_)tld>
  MAIL FROM:<user(_at_)openrelay(_dot_)tld>
  MAIL RTRN:<innocent(_dot_)victim(_at_)example(_dot_)tld>
  RCPT TO:<other(_dot_)innocent(_at_)target(_dot_)tld>

The "submitter" presumably is "innocent(_dot_)victim(_at_)example(_dot_)tld" 
who also is
getting the bounces.  The "sender" is set to something allowed by SPF.


As long as the RHS of SNDR,FROM and RTRN match there's no problem.  Now,
what are the permutations and their consequences.

In the following table:
- RHS1 is the sending domain (DNS should match socket address)
- RHS2 is the origin of the message (or so is claimed)
- RHS3 is some other place
- Only RHS1 is allowed by SPF.
- The local part is irrelevant for this discussion.

 FROM   SNDR   RTRN
-----  -----  -----
 RHS1   RHS1   RHS1   nothing special
 RHS1   RHS1   RHS2   bounces can go to a victim
 RHS1   RHS1   RHS3   bounces go somewhere totally unrelated
 RHS1   RHS2   RHS1   forwarded message from "author". Bounces go to sender
 RHS1   RHS2   RHS2   forwarded, bounces go to the "author"
 RHS1   RHS2   RHS3   forwarded, bounces go elsewhere
other   any    any    mail is refused due to SPF

In the forwarded mail cases:  Why do we trust the domain sending
the message?  The _claim_ it is a forwarded message but how do we
check this is a valid claim?
 
Suppose we also need to check MAIL RTRN against SPF.  This effectively
would allow "RHS2" just like RHS1 is allowed.  But if RHS2 is allowed by
SPF, why not use it in "MAIL FROM" ?

"MAIL SNDR", the author of a message, should already be present in the
headers of the message.  Whay do we gain by duplicating it in the envelope,
and what happens when those two don't match?


Let's pretend you can answer all of my questions, I'm still not convinced
about the commands.  I'd propose:

  MAIL FROM:<real(_dot_)author(_at_)example(_dot_)tld>
  VIA:<forwarder(_at_)firstforwarder(_dot_)tld>
  VIA:<forwarder(_at_)otherforwarder(_dot_)tld>
  ERRORS TO:<bounce(_dot_)processor(_at_)firstforwarder(_dot_)tld>
  RCPT TO:<user(_at_)other(_dot_)tld>

If a forwarder wants to act as a privacy gateway, it should not use
"VIA" nor "ERRORS TO".  This means the message appears to come from
the "otherforwarder.tld" domain and no traces of "example.tld" nor
"firstforwarder.tld" should be visible.

VIA is optional, and should somehow be verified. If "VIA" is used,
the "ERRORS TO" defaults to the last "VIA".  If set, "ERRORS TO"
MUST have a RHS of one of the "VIA" domains, or the "MAIL FROM".
Wherever we send a bounce, we want to know it is not a spoofed address!

In order to verify the authenticity of the VIA and ERRORS TO claims,
a cookie or something similar should be present.  

  MAIL FROM:<real(_dot_)author(_at_)example(_dot_)tld> SIZE=1945 COOKIE=A12B39DE
  VIA:<forwarder(_at_)firstforwarder(_dot_)tld>
  VIA:<forwarder(_at_)otherforwarder(_dot_)tld>
  ERRORS TO:<bounce(_dot_)processor(_at_)firstforwarder(_dot_)tld>

The cookies should be verified at the claimed domain.

(we're talking to otherforwarder, no need to check cookie)
Session to firstforwarder.tld:
  VRFY:<forwarder(_at_)firstforwarder(_dot_)tld> COOKIE=A12B39DE
If passed: Session to example.tld:
  VRFY:<real(_dot_)author(_at_)example(_dot_)tld> SIZE=1945 COOKIE=A12B39DE

Yes, this fails if those domains are unreachable.

And then there's the issue of the bounce being sent from a place
where its receiver does not expect to get it from.  The cookie could
help here as well:

  MAIL FROM:<> COOKIE=A12B39DE
  RCPT TO:<bounce(_dot_)processor(_at_)firstforwarder(_dot_)tld>

Firstforwarder.tld recognizes the message as a bounce and can lookup
the cookie; it presumably has sent a message with the same cookie.
The bounce is not coming from the place where the message was sent but
this doesn't matter: It's verifiable legitimate.

cheers,
Alex
-- 
begin  sig
http://www.googlism.com/index.htm?ism=alex+van+den+bogaerdt&type=1
This message was produced without any <iframe tags


<Prev in Thread] Current Thread [Next in Thread>