Subject: [Asrg] Redirection at SMTP session

From: Jose-Marcio Martins da Cruz <[email-masked]>
Date: Wed, 03 Dec 2008 16:24:31 +0100

Hello,

Someone suggested forwarding at SMTP session, the same way as HTTP does.

As long as forwarding/redirection is something which breaks many other possible mail features (SPF, 
...), it could be something interesting.

A typical SMTP session could be something of the kind :

 >>>RCPT To: [email-masked]
<<<FORWARD To: [email-masked]

This kind of thing isn't an open relay as the SMTP server shall maintain a table/database of 
redirections or, at least, some redirection rules.

Was this kind of thing already discussed in the past ? Any thoughs ?

Regards,

Jose-Marcio
_______________________________________________
Asrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/asrg

---

From: "J.D. Falk" <[email-masked]>
Date: Wed, 03 Dec 2008 21:33:13 +0530

> Someone suggested forwarding at SMTP session, the same way as HTTP does.
 [ . . . ]
> Was this kind of thing already discussed in the past ? Any thoughs ?

551  User not local; please try <forward-path>

It's been around since at least RFC 821, possibly longer.  I've never seen
it in the wild, though.

---

From: Jose-Marcio Martins da Cruz <[email-masked]>
Date: Wed, 03 Dec 2008 17:19:54 +0100

> 551  User not local; please try <forward-path>

This is a permanent error - so an human is needed to interpret this.

I was thinking about something like (nor 4xx nor 5xx) :

303 FORWARD [email-masked]

> It's been around since at least RFC 821, possibly longer.  I've never seen

Someone though about.

-- 
  ---------------------------------------------------------------
  Jose Marcio MARTINS DA CRUZ           http://j-chkmail.ensmp.fr
  Ecole des Mines de Paris
  60, bd Saint Michel                      75272 - PARIS CEDEX 06
  mailto:[email-masked]
_______________________________________________
Asrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/asrg

---

From: SM <[email-masked]>
Date: Wed, 03 Dec 2008 08:43:48 -0800

>This is a permanent error - so an human is needed to interpret this.

There's also the 251 reply code.  That's for address correction.

>303 FORWARD [email-masked]

You can get the same functionality with a 251 reply code where the 
MTA accepts the message and forwards it to the new address.  It's a 
redirection in the sense that the MTA is doing an address rewrite and 
relaying or delivering the message to the new mailbox.

There is no need for a new reply code if the text after the reply 
code is structured.  You still have to determine how to relay the new 
address back to the MUA as SMTP does hop by hop delivery.  HTTP, on 
the other hand, requires a direct connection between the server and 
the user agent.  Even if there is a proxy in the middle, the user 
agent still has access to the HTTP reply code.

Regards,
-sm

---

From: Jose-Marcio Martins da Cruz <[email-masked]>
Date: Wed, 03 Dec 2008 18:51:42 +0100

> 
> You can get the same functionality with a 251 reply code where the MTA 
> accepts the message and forwards it to the new address.  It's a 

That's what I want to avoid : "accept and forward", mainly the "accept" part.

> 
> There is no need for a new reply code if the text after the reply code 
> is structured.  You still have to determine how to relay the new address 
> back to the MUA as SMTP does hop by hop delivery.  HTTP, on the other 
> hand, requires a direct connection between the server and the user 
> agent.  Even if there is a proxy in the middle, the user agent still has 
> access to the HTTP reply code.

The idea is why, in this case, SMTP can't work the same way as HTTP ? The goal is, if wanted, be 
able to not work in "store and forward" mode or ("hop by hop", as you say).

---

From: "Chris Lewis" <[email-masked]>
Date: Wed, 3 Dec 2008 13:23:07 -0500

> able to not work in "store and forward" mode or ("hop by hop", as you say).

The existing use of SMTP "store and forward" (to another MTA) is perhaps
primarily to shield internal MTAs from external access.

Eg: To get to me, you have to hop thru several MTAs:

1) The spam filtering engines
2) The sendmail perimeter array
3) The Exchange cloud
4) The mailbox server

2-4 aren't connected to the Internet, and we don't want them to be for
security reasons.

(1) is effectively not a store-and-forward MTA to (2) (it's analogous to
a packet relay).  Secondly, we may be eliminating (2) in the
not-to-distant future.  However, we still don't want anything but (1)
directly connected to the Internet.  An HTTP-style redirect won't work.

Similarly, on outbound, you have to traverse thru several mail servers,
each with different functionality, funnelling thru a couple very
specific outbound-only servers.  You don't want redirection to the
outbounds directly.
_______________________________________________
Asrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/asrg

---

From: SM <[email-masked]>
Date: Wed, 03 Dec 2008 11:35:28 -0800

>That's what I want to avoid : "accept and forward", mainly the "accept" part.

You could use the 551 reply code then.  The message gets rejected and 
a notification gets sent back to the MUA.  Currently, MUAs treat that 
as a delivery failure and don't take any specific action.

>The idea is why, in this case, SMTP can't work the same way as HTTP 
>? The goal is, if wanted, be able to not work in "store and forward" 
>mode or ("hop by hop", as you say).

If you think of HTTP, the user agent gets the redirect code and a 
link to the new resource and generates another request.  MUAs act 
more like dumb agents and don't have such a functionality.

We usually have two endpoints for communication.  When we send a 
"message", the receiver needs to acknowledge receipt or else provide 
some type of signalling to detect failure.  If we want to avoid 
storage or hop by hop, we'll need some signalling between the two 
ends.  It's easier to design a new system than to put all that in 
SMTP.  The idea brings us to direct connection mode which we see in 
the HTTP model.  In the SMTP model, the idea is to produce (and 
deliver) a message whereas in HTTP, it's about consuming a resource.

Regards,
-sm

---

From: Matthias Leisi <[email-masked]>
Date: Wed, 03 Dec 2008 22:28:45 +0100

> directly connected to the Internet.  An HTTP-style redirect won't work.

If I understand Jose-Marcio corretly, that's not where "303 FORWARD
[email-masked]" would come into the picture.

I guess the basic idea is for cases where it is feasible and practical
for the (intermediate) destination server to tell the sending server to
deliver the message to somewhere else.

Such a step would eliminate a number of potential forwarding issues (eg
that the forwarding target server may/should identify the forwarding
server as a legitimate forwarder and not as a spam source per se).

However I'm not sure that there would be sufficiently broad usage that
it would gain sufficient attraction and adoption, but it could be an
interesting SMTP extension, especially for sites with a large forwarding
user base (like Google etc).

-- Matthias

---

From: Jose-Marcio Martins da Cruz <[email-masked]>
Date: Wed, 03 Dec 2008 22:34:44 +0100

Hello Matthias,

> deliver the message to somewhere else.

You got the idea !!!!!!!

And I agree with all your comments below !