Subject: [Asrg] 3b. SMTP Session Verification - The Forwarding Problem

From: Brett Watson <[email-masked]>
Date: Tue, 10 Feb 2004 15:44:31 +1100

Philip Miller wrote (in reference to the verification problem during mail 
forwarding):
> Since forwarders are clearly trusted by the user, we should make it possible
> for the forwarder to deliver directly to the user's inbox, rather than
> transferring messages like any other mailer.

I disagree. As you go on to say, this breaks instances where there is more 
than one forwarding, and there is no standard way to deliver a message into 
an inbox other than SMTP anyhow. (Yes, IMAP has APPEND, and those people who 
are using IMAP now could already be using this as a forwarding mechanism if 
they wanted to.)

I have an alternative suggestion: make the act of forwarding explicit in the 
SMTP dialogue.

If mail from <A> to <B> is forwarded to <C>, then this normally results in a 
dialogue between the MTAs for <B> and <C> including "MAIL From:<A>" and "RCPT 
To:<C>" without explicit mention of <B> anywhere. This is indistinguishable 
from the case where a user at the MTA for <B> impersonates <A>.

The forwarding information could be made explicit in something like the 
following hypothetical ESMTP extension. Let the ESMTP keyword be "VIA", which 
allows the additional parameter "Via:" in the MAIL command. The conversation 
between the MTAs for <B> and <C> now looks as follows.

C: 220 C.domain SMTP server ready
B: EHLO B.domain
C: 250-C.domain greets B.domain
C: 250 VIA
B: MAIL From:<A> Via:<B>
C: 250 OK
B: RCPT To:<C>
C: 250 OK
(etc.)

The MTA for <C> can now perform LMAP-like tests against the "Via:<B>" claim. 
Where there is more than one intermediate forwarding step, the "Via:" clause 
can specify a comma-separated list of paths, the last of which the sending 
system claims to represent. Thus, if <C> forwarded to <D> using the same 
system, the critical line would read, "MAIL From:<A> Via:<B>,<C>".

Aside from making the mail system easier to analyse (by preserving more 
information about the delivery process), this would allow recipients to 
explicitly reject forwarded mail in cases where they are not expecting any.

It may be preferable to insert the "Via:" clause in the RCPT command (as in 
"RCPT To:<C> Via:<B>"), because there are some obscure cases where this would 
be more efficient. Finding them is left as an exercise for the reader at this 
time.

Regards,
TFBW

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

---

From: "Jon Kyme" <[email-masked]>
Date: Tue, 10 Feb 2004 08:50:04 +0000

Brett Watson wrote: 
> be more efficient. 

That's as maybe. It would be be less "efficient" for most messages with
multiple recipients.

There's been discussion of ENVID on this list.

--

---

From: Brett Watson <[email-masked]>
Date: Wed, 11 Feb 2004 00:32:07 +1100

I should mention briefly that my suggested "VIA" ESMTP extension can not be 
implemented exactly as I have presented it in earlier postings, due to syntax 
constraints. The production for "esmtp-value" does not allow the "space" or 
"=" characters, but the production for "mailbox" does. RFC 3461 faces the 
same problem and uses a simple encoding it calls "xtext".

The protocol is still theoretically implementable, but it would be somewhat 
uglier than my examples suggest if the esmtp-parameter mechanism were used. 
Such is life. It's intended to be one idea in a pool of suggestions rather 
than an immediate course of action in any case.

Regards,
TFBW

---

From: "Jon Kyme" <[email-masked]>
Date: Wed, 11 Feb 2004 15:10:47 +0000

> Jon Kyme wrote:
> >>  http://spf.pobox.com/draft-mengwong-sender-rewrite-01.txt
> > 
> > [observations snipped]
> > 

> 
> 
> There are some concerns with the length limits of certain RFC 2822 
> headers such as "Return Path" which might cause problems with sender 
> rewriting.
>
 
Yes, these concerns are addressed by the use of some max-length "cookie"
rather than an ever-growing (with each forward) verp-like string.

Of course, this loses the sender string's "trace" 
(which is still available in the headers - so no real loss ?) 
but also limits the risk of exploitation via an explicit return-path
"routing".

It would require the forwarder to maintain some data,
which will have privacy/security implications.

Some kind of envelope modification (i.e. more than just RCPT) is probably
required for happy forwarding in an environment made unfriendly by LMAP.

It's not a big deal really, but it can't be ignored.

--