Pull has the distinct advantage of maintaining one submission protocol. Can be used with multiple retrieval protocols. Message Submission Overview. Sending an email message consist of the following steps: 1) initiation of a new draft (on MUA), 2) draft editing (on MUA; draft/template can be saved on IMAP server), 3) message assembly [producing final message], 4) message submission [inserting the assembled message into the SMTP infrastructure]. Traditionally 3) is done on MUA as well. Referenced bodyparts are downloaded/uploaded all the time. Pull Strategy: 3 variants 1) "Pure" [BURL] Variant Messages assembly and submission is done as a single step on SUBMIT server using BURL (that might contain multiple URLs, some of them URLAUTH) Notes: Fully constructed message (with no external references) is NOT AVAILABLE on IMAP server 2) [BURL]/[CATENATE] Variant [CATENATE] extension to [IMAP] is then used to upload the message to the IMAP server and assemble it. A single IMAP URLAUTH is specified in BURL. Notes: Fully constructed message (with no external dependencies) is left on IMAP server CATANATE has to be extended to support arbitrary URLs BURL can be simplified to support a single URL only 3) [BURL]/Embedded URI Variant Messages saved on the [IMAP] server via an APPEND command. External data is indicated by URIs which are embedded in the message in some easily-identifiable form (new header or content-type parameter) A single IMAP URLAUTH is specified in BURL. Message assembly is done entirely on SUBMIT server. Notes: Fully constructed message (with external references) is left on IMAP server BURL can be simplified to support a single URL only This is "draft-friendly": the client can simply download the draft from the IMAP server and re-edit it, without the burden of downloading the external data (since it hasn't yet been incorporated into the message) or fetching the message structure, parsing it, and then fetching the editable parts. The choice between 1-2 and 3 depends on whether a full message without or with external references is left on IMAP server. URLAUTH extends IMAP URLs by adding 3 additional parameter to an IMAP URL ";URLAUTH=" - ":" <128 bit signature in hex> ";EXPIRE=" One (and only one) of AUTHID/AUTHROLE is required: ";AUTHID=" - authorize as to the IMAP server. ";AUTHROLE=" - only a userid authorized to act in the given role is permitted to use this URL. Currently defined roles are: "compose" (a message composition entity), "submit" (a message submission entity), "authuser" (any authorized user of the IMAP server), and "anonymous" (anyone, including anonymous users and authorized users of the IMAP server). URLFETCH - FETCH message or message body part by URL. URLFETCH response returns data if and only if the URL can be validated. URLFETCH response may return multiple messages/their body parts at once. Example of URLAUTH usage: S: * OK [CAPABILITY IMAP4REV1 URLAUTH] example.com IMAP server ready C: a001 LOGIN fred secret S: a001 OK fred logged in C: a002 URLFETCH "imap://joe@example.com/INBOX;uid=20;section=1.2 ;authid=fred;urlauth=hmac-md5:91354a473744909de610943775f92038" S: * URLFETCH "imap://joe@example.com/INBOX;uid=20;section=1.2 ;authid=fred;urlauth=hmac-md5:91354a473744909de610943775f92038" {28} S: Si vis pacem, para bellum. S: S: a002 OK URLFETCH completed