[ On Saturday, April 24, 2004 at 06:57:36 (-0700), Marc Perkel wrote: ]
> Subject: [Exim] Using IMAP protocol to SEND email ??
>
Now you're getting on the right track! ;-)
> OK - after struggling with the idea of SPF last night and being fairly
> unimpressed with it - it got me thinking about solutions to the problem
> of who relays for whom.
First off you have to have to define how, and why, you'll identify the
sender.
> Obviously - you don't want anyone relaying for anyone.
It depends on what you mean by "relaying". On first read I
automatically agreed with you, but on further consideration I don't
really see any problem with "relaying" outbound mail from any given
sender provided that they're using your own trusted network. That's the
whole purpose of an oubound mail gateway after all. :-)
Of course even a client on a trusted network may be acting on the behalf
of an untrusted, unauthorized party (e.g. a spammer-owned client host),
thus the need for stronger authentication of the client _user_...
> So - since you are already connected to a server to get your email - and
> you are already AUTHENTICATED to that server - then who not let IMAP do
> the SENDING of the email?
Indeed, why not?
Personally I've always thought this would be the "right" solution,
though it is tricky to get exactly "right". :-)
There have already been several proposals along this line, the most
interesting (and most recent) of which are:
IMAP-Push http://www.ietf.org/internet-drafts/draft-gellens-lemonade-push-00.txt
Push-IMAP http://www.ietf.org/internet-drafts/draft-maes-lemonade-p-imap-01.txt
(the submission part, XDELIVER, is only a small part of the latter)
Seel also:
http://www.ietf.org/html.charters/lemonade-charter.html
http://www.ietf.org/internet-drafts/draft-ietf-lemonade-goals-02.txt
Unfortunately many folks have settled on "Message Submission" (RFC 2476)
for this purpose for now and this fact makes it far more difficult to
float an IMAP extension now, and even the recent gellens/lemonade draft
may not go very far without a lot more support from the rest of the
community (even if it gets published as an RFC, though note it was
submitted by its author, not directly by the lemonade group as a whole).
For example I'd love to see an implementation of it in Cyrus IMAPd and
Pine (and then I'd deploy it!).
Some folks (even those I thought would know better) foolishly believe
that IMAP message submission would "double the amount of work" an IMAP
server would have to do, but clearly they haven't thought through all
the facts about this issue very well. There are obviously some issues
here, but I don't think they're anywhere near as complex as many people
seem to want to make them.
Interestingly RFC 2476, the current "standard", was authored/edited by
the very same person (Randy Gellens) now proposing IMAP Message
Sumission (IMAP Push).
Another potentially huge advantage of IMAP Message Submission is the
"pull" concept which would allow "clients to send new messages
consisting of or containing all or parts of previously received messages
without having to download and (re)upload the data."
IMAP-Pull http://www.ietf.org/internet-drafts/draft-crispin-lemonade-pull-01.txt
Somewhat also along the same lines:
IMAP-BURL http://www.ietf.org/internet-drafts/draft-newman-lemonade-burl-00.txt
Note the lemonade-sacntioned "submit" draft is actually only just a
half-baked survey of the subjects covered in detail by more specific
Gellens, Crispin, and Newman drafts referenced above:
http://www.ietf.org/internet-drafts/draft-ietf-lemonade-submit-01.txt
Of course all of these proposals are _FAR_ more complex than they really
need to be. All IMAP clients I'm aware of can already speak SMTP (or
are very closely tied to software that can). All that's really required
for the basic functionality we're talking about is for the IMAP server
to support an extension which would allow the client to request that a
channel be opened to an SMTP server local to the IMAP server and then
the IMAP server doesn't need to do anything special other than act as a
secure proxy tunnel (except maybe keep an eye on the traffic and run an
idle timer to close the tunnel if it goes inactive for too long).
Fortunately I'm not the only one who's ever thought of this, though even
this draft of a similar proposal is almost infinitely more complex than
what I have in mind:
http://www.ietf.org/internet-drafts/draft-royer-lemonade-submit-01.txt
Un(?)fortunately this proposal has died for now -- perhaps because it is
indeed far too complex for what's needed.
I suppose it's long past the time I should have written up my idea and
submitted it to the IETF. I suspect it would only take about a day or
so to fully implement and completely test in Cyrus IMAPd, and similarly
little time to implement in any decent IMAP client (though personally I
wouldn't even want to tackle Pine -- maybe just Emacs VM, which should
only take an hour or so to implement). I.e. it would take a hell of a
lot longer to write up the ID and submit and work it through the IETF to
becoming an RFC it than to have working code!
--
Greg A. Woods
+1 416 218-0098 VE3TCP RoboHack <woods@???>
Planix, Inc. <woods@???> Secrets of the Weird <woods@???>
