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:
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.
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
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).
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
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...
--
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg