Subject: Re: [Asrg] 3b. SMTP Session Verification - explicit source routes]

From: "Za'mbori, Zolta'n" <[email-masked]>
Date: Sat, 17 Jan 2004 22:54:34 +0100

Jon Kyme wrote:
> But of course, these source routes MUST NOT be truly *explicit* - or a new
> channel for abuse is opened up - the "bounce path".

I found an example about these source routes in RFC2821, Page 75:

Step 2  --  Relay Host to Destination Host

S: 220 xyz.com Simple Mail Transfer Service Ready
C: EHLO foo.com
S: 250 xyz.com is on the air
C: MAIL FROM:<AT foo.com:jpq AT bar.com>
S: 250 OK
C: RCPT TO:<jones AT xyz.com>
S: 250 OK
C: DATA

If the SMTP client IP is designated by 'foo.com' than the session is
verified, mail is acceptable by 'xyz.com'. (And of course it can be spam
but 'foo.com' is accountable for it.)

Can You explain where is the new "bounce path"?

> Without a
> complementary, and secure, Sender Rewriting Scheme (or something), I can't
> see that a system like SPF is much use in the real world.

For me SRS is too complicated. But i am not an expert so it means nothing.

z2

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

---

From: "Jon Kyme" <[email-masked]>
Date: Sun, 18 Jan 2004 10:05:23 +0000

> I found an example about these source routes in RFC2821, Page 75:

OK, we're required not to use source routes nowadays - in "contemporary
clients" - so some equivalent is called for. But we can use the source
routing notation if you like.

> C: RCPT TO:<jones AT xyz.com>

The question is what happens if this message is undeliverable at xyz.com?
xyx.com generates a DSN to <AT foo.com:jpq AT bar.com>,
foo.com relays it to bar.com. 

> Can You explain where is the new "bounce path"?

In the above example foo.com is an open relay when handling the DSN
(bounce).

> For me SRS is too complicated. But i am not an expert 

Me neither. But I gather it's just a way of representing the source route
in the envelope sender address.

To go back to the example - to make sure that xyz.com sees a match between
sending IP and (envelope) sender, foo.com has to rewrite the sender
(previously JQP_AT_bar.com) to something like JQP**bar.com_AT_foo.com.
foo.com has to be capable of relaying bounces by decoding this "path" when
it sees it in a RCPT.

But of course, this is trivially abused (as above) to get foo.com to relay
anything to JQP_AT_bar.com (or to anywhere else).

This return path encoding needs to be secured. A simple method might be for
foo.com to assign an unique identifier to every message forwarded and to
record the sender associated.

i.e. 
C: MAIL FROM:<fwd-123456_AT_foo.com>

then when a bounce for fwd-123456_AT_foo.com is seen we can look it up in
our database and get JQP_AT_bar.com - or nothing (in case of forgery).

Obviously - a real system needs to be more secure that this...

--

---

From: "Za'mbori, Zolta'n" <[email-masked]>
Date: Sun, 18 Jan 2004 12:17:41 +0100

> In the above example foo.com is an open relay when handling the DSN

Thank You! Now I start to understand the forwarding and session 
verification problem and the requirements behind SRS.

z2

---

From: Daniel Feenberg <[email-masked]>
Date: Sun, 18 Jan 2004 07:24:32 -0500 (EST)

> > I found an example about these source routes in RFC2821, Page 75:

Is this so significant that it has to be addressed? After all, is it so
terrible that, if [email-masked] wants his mail forwarded to
[email-masked], he wants example2.com to have some anti-spam mechanism
in place? Furthermore, if example2.com wants to base its decision on
the original connection address, it has a very easy decision to make,
since the message should have come from example1.com, any other would be
invalid. Or am I misunderstanding the problem? Can someone make the new
spam path explicit?

---

From: "Jon Kyme" <[email-masked]>
Date: Sun, 18 Jan 2004 14:28:48 +0000

Daniel Feenberg wrote:
> > > > But of course, these source routes MUST NOT be truly *explicit* -
> or a
> > > new

I think the problem is that this requires example1.com to have that
anti-spam mechanism in place also.

Consider:

[email-masked]  addresses mail to [email-masked]

recipient.example MX points to intermediate.example

bob and all his colleagues wish to use some SPF based system.
So they deploy it on recipient.example.

To make things work simply (including bounces) the nice people at 
intermediate.example arrange to do sender rewriting so that alice's mail
comes to bob with a sender address (envelope) of
[email-masked]. 
All is well.

Now, if alice sends mail to [email-masked]
the sender is rewritten as above, recipient system can form a DSN and send
it to [email-masked], intermediate can decode
this "address" and determine that the DSN needs to go to to
[email-masked]

All is well.

Now, sadly, I come along and send my viagra-adv to
[email-masked],
[email-masked],
...

In this *simple* *dumb* example intermediate is an open relay.

Or am I missing something?

As far as I can tell, it seems that one has to either (a) secure
the sender-rewriting /decoding or (b) to require that intermediate has some
highly effective antispam protection in place or (c) throw away bounces.
I'd guess (a) is going to be better.

--

---

From: "Za'mbori, Zolta'n" <[email-masked]>
Date: Sun, 18 Jan 2004 17:49:40 +0100

> routing notation if you like.

I like soure routing notation because using existing syntax to express 
new needs seems to be a good thing.

I now see that session verification implies expression of forwarding 
between mailboxes. Maybe extending the host relay path syntax (RFC821 
"@ONE,@TWO:JOE@THREE") to be a mailbox forward path syntax 
("mb1@ONE,mb2@TWO:JOE@THREE") can help in some cases.

A simple example:

1 - Sender to Forwarder:

mail from:<x@a>
rcpt to:<y@b>

(Forwarder decide that there is a forwarding rule from 'y@b' to 'z@c')

2 - Forwarder to Receiver:

mail from:<y@b:x@a>
rcpt to:<z@c>

(Receiver can verify that the SMTP client IP is authorized by 'b'.)

3 - Receiver back to Forwarder:

mail from:<z@c:>   (bounce)
rcpt to:<y@b:x@a>

(Forwarder decide that there is a forwarding rule from 'y@b' to 'z@c'. 
Otherwise it is an unauthorized forward attempt.)

4 - Forwarder back to Sender:

mail from:<y@b:>     (bounce variation 1)
mail from:<>         (bounce variation 2)
rcpt to:<x@a>

What do You mean?

z2

---

From: "Jon Kyme" <[email-masked]>
Date: Sun, 18 Jan 2004 16:55:32 +0000

> > > > channel for abuse is opened up - the "bounce path".

Just to clarify -  Meng Weng Wong
covers this well in SRS
( http://spf.pobox.com/draft-mengwong-sender-rewrite-01.txt )

I'm not sure that it's been stressed sufficiently that this is probably
*essential* for anyone doing forwarding in a SPF environment.

--