ietf-asrg
[Top] [All Lists]

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

2004-02-09 21:49:06
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
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg