Re: [imap5] Feature set? - was Re: Designing a new replacement protocol for IMAP

[Dan White <[e-mail]>]

On 02/17/12 10:00 +1300, Adrien de Croy wrote:
>
>
>On 17/02/2012 5:40 a.m., Tony Finch wrote:
>>Adrien de Croy<[e-mail]>  wrote:
>>>>With XSEND, you upload the message to IMAP first, then you say:
>>>>
>>>>TAG XSEND UID
>>>how do you provide the SMTP forward path?  Is that scraped from the headers?
>>That's the right thing to do. You also need to do BCC: processing.
>>(sendmail -t does the right thing.)
>
>I think the guys that developed SMTP would disagree with you.  The 
>reason the envelope is even specified in SMTP rather than the 
>receiver simply scraping them out of the message, is that sometimes 
>you need to deliver a message somewhere other than the To: / bcc: 
>headers.
>
>>The rationale for BURL is that there is more to the SMTP envelope than
>>just the sender and recipient addresses - in particular there are the DSN
>>attributes. There's a somewhat ugly and ill-defined split between
>>information for MTA processing (in the envelope) and information for MUA
>>processing (in the headers - see MDN for example). But in fact MTAs do
>>header processing too, so there no practical advantage to ESMTP envelope
>>extensions and a lot of complexity disadvantage.
>>
>>There are a few envelope extensions: DSN, future release, message
>>tracking, CONNEG and CONPERM facsimile media conversion, and 8BITMIME +
>>BINARYMIME. If you want to eliminate BURL you need to either define a
>>mapping from headers to the extension parameters that you want to support,
>>or embed ESMTP inside IMAP.
>
>yep, I'd definitely go for embedding SMTP into IMAP... since
>
>a) SMTP is a trivially simple protocol for an IMAP server to use to 
>submit a message on behalf, whereas an IMAP client is much more 
>complicated,
>b) take a look at the security implications in the BURL RFC.

However, spam is a problem caused by a deficiency (or whatever you want to
call it) within the smtp protocol. imap does not directly or indirectly lead
to the generation of spam, unless you want to consider backscatter from a
sieve notification to be spam.

smtp (or submission) is one of those things that's actually easy to
configure in an email client. I fear that if the two get combined on the
same port that imap server IPs may start to get caught up in the cat
and mouse game spam parsers play.

-- 
Dan White