SMTP adaptation with OPES draft-ietf-opes-smtp-00.txt OPES WG - - PowerPoint PPT Presentation

▶
smtp adaptation with opes
SMART_READER_LITE
LIVE PREVIEW

SMTP adaptation with OPES draft-ietf-opes-smtp-00.txt OPES WG - - PowerPoint PPT Presentation

Nov 26, 2023 264 likes •498 views

SMTP adaptation with OPES draft-ietf-opes-smtp-00.txt OPES WG meeting on 64 th IETF in Vancouver, BC, Canada Martin Stecher (martin.stecher@webwasher.com) Clemens Perz (cperz@allaboutit.lu) Presented by Paul Knight (paul.knight@nortel.com)

slide-1
SLIDE 1

2005-11-08 SMTP Adaptation with OPES OPES WG on 64th IETF in Vancouver 1

SMTP adaptation with OPES

draft-ietf-opes-smtp-00.txt OPES WG meeting on 64th IETF in Vancouver, BC, Canada Martin Stecher (martin.stecher@webwasher.com) Clemens Perz (cperz@allaboutit.lu) Presented by Paul Knight (paul.knight@nortel.com)

slide-2
SLIDE 2

2005-11-08 SMTP Adaptation with OPES OPES WG on 64th IETF in Vancouver 2

Content

  • What is OPES/SMTP?
  • Operation Flow of an OPES SMTP System
  • Tracing
  • Bypass
  • (Optional Details)
slide-3
SLIDE 3

2005-11-08 SMTP Adaptation with OPES OPES WG on 64th IETF in Vancouver 3

What is OPES/SMTP?

  • From our charter:

– The OPES [WG] has previously [...] developed a protocol suite for invocation and tracking of OPES services inside the

  • net. The protocol suite includes a generic, application-

agnostic protocol core (OCP Core) that is supplemented by profiles specific to the application-layer protocol used between the endpoints. So far, the WG has specified an OCP profile for HTTP, which supports OPES services that

  • perate on HTTP messages.

– In a next step, the WG will specify one or more OCP profiles that will support OPES services operating on SMTP.

slide-4
SLIDE 4

2005-11-08 SMTP Adaptation with OPES OPES WG on 64th IETF in Vancouver 4

What is OCP? OCP = OPES Callout Protocol

Client Server OPES processor pre-processing post-processing Callout server OCP-Client OCP-Server adaptation OCP wrapped application data OCP control messages OCP scope

slide-5
SLIDE 5

2005-11-08 SMTP Adaptation with OPES OPES WG on 64th IETF in Vancouver 5

OCP/SMTP is the current target

OCP Core

HTTP profile RTSP profile FTP profile SMTP profile MIME profile

... TCP/IP

Other Transports Application protocol agnostic Application protocol binding assumes TCP as transport

 RFC 4236  RFC 4037 current focus

slide-6
SLIDE 6

2005-11-08 SMTP Adaptation with OPES OPES WG on 64th IETF in Vancouver 6

“SMTP adaptation with OPES” is more!

  • The SMTP adaptation draft does not only

specify the OCP/SMTP profiles.

  • It also has to deal with Tracing, Bypass and
  • ther OPES requirements
  • Building on:

– “Requirements for OPES Callout Protocols” [RFC3836] – “OPES Treatment of IAB Considerations” [RFC3914] – “Security Threats and Risks for OPES” [RFC3837] – and others

slide-7
SLIDE 7

2005-11-08 SMTP Adaptation with OPES OPES WG on 64th IETF in Vancouver 7

recap: Operation Flow of an OPES SMTP System

Mail Client

MUA

Mail Server

MSA MTA

Mail Gateway

MTA MTA

Mail Server

MTA MDA

Mail Client

MUA

Callout server Callout server Callout server Callout server OCP/SMTP OCP/SMTP OCP/SMTP OCP/SMTP Possible Activation Points (usually just one

  • f these)

MUA = Mail User Agent; MTA = Mail Transfer Agent; MSA = Mail Submission Agent; MDA = Mail Delivery Agent

slide-8
SLIDE 8

2005-11-08 SMTP Adaptation with OPES OPES WG on 64th IETF in Vancouver 8

Two profiles

  • Defines two profiles for OCP/SMTP:

– http://iana.org/opes/ocp/SMTP/sender Used while or just before sending a message – http://iana.org/opes/ocp/SMTP/receiver Used while or just after receiving a message

slide-9
SLIDE 9

2005-11-08 SMTP Adaptation with OPES OPES WG on 64th IETF in Vancouver 9

Profile negotiation

  • OPES processor (the MTA) offers application

message parts that it allows to adapt (Adaptive-Parts) and parts that it can provide as auxiliary information (Informative-Parts)

  • Callout server responds with the subset of

parts that it plans to adapt and wants to see as additional meta information.

slide-10
SLIDE 10

2005-11-08 SMTP Adaptation with OPES OPES WG on 64th IETF in Vancouver 10

Tracing

  • Trace headers MUST be added by the OPES

processor; same as OCP/HTTP (RFC 4236)

  • Example:

Received: from gateway.example.com ([192.0.2.138]) by mail.example.com with testserver; Mon, 10 Oct 2005 05:37:19 +0200 Received: from mail2.example.org [192.0.2.99] by gateway.example.com id 33W9WIMC; Mon, 10 Oct 2005 05:35:55 +0200 OPES-System: http://mail.example.com/opes?id=33W9WIMC OPES-System: http://gateway.example.com/opes?session=33W9WIMC OPES-Via: http://gateway.example.com/opes?session=33W9WIMC, http://www.opes-services-4u.com/cat/?sid=123, http://www.opes-services-4u.com/cat/?sid=124, http://www.opes-services-4u.com/cat/?sid=125 ; mode=A Subject: Test From: "Steve" <steve@example.org> To: "Sandra" <sandra@example.com>

slide-11
SLIDE 11

2005-11-08 SMTP Adaptation with OPES OPES WG on 64th IETF in Vancouver 11

Tracing (2)

  • Adding trace header gives OPES trace

notifications to message receiver.

  • IAB Considerations say the sender must be

able to receive the trace information

  • An SMTP Trace extension could be

supported to allow the message sender to receive trace notifications (see list of open issues at end)

slide-12
SLIDE 12

2005-11-08 SMTP Adaptation with OPES OPES WG on 64th IETF in Vancouver 12

Open Issues (1) – Tracing info for sender

  • While SMTP tracing information for the email

recipient is trivial, reliable notifications for the email sender are a problem (a general problem with SMTP not only for OPES).

  • How does that correspond to the IAB

considerations?

  • What do you think about Delivery Status

Notifications (RFC3461) and/or Message Tracking (RFC3885) to build on for OPES/SMTP?

slide-13
SLIDE 13

2005-11-08 SMTP Adaptation with OPES OPES WG on 64th IETF in Vancouver 13

Bypass

  • IAB Considerations say the sender must be

able to receive the trace information

  • An SMTP extension could be supported to

allow OPES bypass

  • Just adding a header to an email message

comes too late if bypass of an RCPT command adaptation is requested (see list of open issues at end)

slide-14
SLIDE 14

2005-11-08 SMTP Adaptation with OPES OPES WG on 64th IETF in Vancouver 14

Open Issues (2) - Bypass

  • OPES bypass is usually client controlled.

Does that really mean email recipient controlled here?

  • It is hard to check the client‘s bypass

requests in a sender centric OPES system.

  • The whole bypass idea is an issue for

protocols that do not have client requests.

  • Is the definition of an SMTP extension the

solution?

  • Or do we need an out-of-band solution?
slide-15
SLIDE 15

2005-11-08 SMTP Adaptation with OPES OPES WG on 64th IETF in Vancouver 15

Optional Details

slide-16
SLIDE 16

2005-11-08 SMTP Adaptation with OPES OPES WG on 64th IETF in Vancouver 16

List of message parts

  • Many different message parts are available:

– HELO: The argument of the HELLO command – MAIL: The argument of the MAIL command – RCPT: The argument of the RECIPIENT command – VRFY: The argument of the VERIFY command – EXPN: The argument of the EXPAND command – RAWDATA: The complete mail data which is sent after the DATA command – ALLHEADERS: The header of the email data – SINGLEHEADERS: Some or all header fields of the email data, each to be sent in a separate OCP message. – BODY: The body of the email data as defined – SECTIONS: Sections of the email body (for example MIME sections), each to be sent in a separate OCP message.

slide-17
SLIDE 17

2005-11-08 SMTP Adaptation with OPES OPES WG on 64th IETF in Vancouver 17

Negotiation Example 1

[P=OPES processor, S=Callout Server] P: NO ({"38:http://iana.org/opes/ocp/SMTP/receiver" Adaptive-Commands: (RCPT,DATA) Informative-Commands: (IP,HELO,MAIL) }) SG: 25 ; S: NR {"38:http://iana.org/opes/ocp/SMTP/receiver" Adaptive-Commands: (DATA) Informative-Commands: (MAIL,RCPT) } SG: 25 ;

slide-18
SLIDE 18

2005-11-08 SMTP Adaptation with OPES OPES WG on 64th IETF in Vancouver 18

Negotiation Example 2

[P=OPES processor, S=Callout Server]

P: NO ({"38:http://iana.org/opes/ocp/SMTP/receiver" Adaptive-Commands: (MAIL,RCPT) Informative-Commands: (IP,HELO,SINGLEHEADERS) }) SG: 25 ; S: NR {"38:http://iana.org/opes/ocp/SMTP/receiver" Adaptive-Commands: (MAIL,RCPT) Informative-Commands: (IP,HELO,SINGLEHEADERS) Header-List: (From,To,Reply-To,Received) } SG: 25 ;

slide-19
SLIDE 19

2005-11-08 SMTP Adaptation with OPES OPES WG on 64th IETF in Vancouver 19

Message Flow

  • Data Use Mine (DUM) and Data Use Yours

(DUY) messages are used to exchange the application message parts

  • DUM, DUY are defined in OCP Core
  • Additional parameters are added

– Allow: OPES processor lists which additional parameters are supported – SMTP-Error: Callout server replies with an SMTP error instead of content adaptation (for example: “550 No such user here”) – Add-Header: Callout server asks the OPES processor to add a header to the email.

slide-20
SLIDE 20

2005-11-08 SMTP Adaptation with OPES OPES WG on 64th IETF in Vancouver 20

Example (1)

DUM 72 1 0 Kept: 0 AM-Part: MAIL 19:<steve@example.org> ; DUM 72 1 19 Kept: 19 AM-Part: RCPT 18:<paul@example.com> ; DUM 72 1 37 Kept: 37 AM-Part: RAWDATA 49:From: steve@example.org To: sandra@example.com ; DUM 72 1 86 Kept: 86 AM-Part: RAWDATA 41:Subject: Test Hi, this is a test! . ;

slide-21
SLIDE 21

2005-11-08 SMTP Adaptation with OPES OPES WG on 64th IETF in Vancouver 21

Example (2)

Example: P=OPES processor, S=Callout Server P: DUM 72 1 0 Kept: 0 AM-Part: RCPT Allow: (SMTP-Error) 18:<paul@example.com> ; S: DUM 72 1 0 AM-Part: RCPT SMTP-Error: "21:550 No such user here" 0: ;

slide-22
SLIDE 22

2005-11-08 SMTP Adaptation with OPES OPES WG on 64th IETF in Vancouver 22

SMTP Extensions

  • OCP/SMTP is prepared to handle SMTP

extensions

– The callout server lists the SMTP extensions it knows and supports in its negotiation response message (with the same keyword that is used in EHLO responses) – Message part list is extendable – The OPES processor can then send the data in the same way to the callout server as it would do to SMTP receivers – Extension meta information via AM-OPT param