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