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<[email protected]> 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
_______________________________________________
imap5 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/imap5