On 11/07/2010 04:39 AM, Liam wrote:
On Sat, Nov 6, 2010 at 8:15 PM, Jeroen Geilman <[email protected]
<mailto:[email protected]>> wrote:
You're again mixing up clients and servers.
I'd need more pertinent information to hazard a guess what you're
trying to achieve here.
Here's a schematic:
[postfix] >--smtp/lmtp--> [custom gateway] >--websocket-->
[websocket clients]
Yes, as I said, SMTP seems the best solution for this.
1)attempt delivery 2)contact
client 3)send ack
5)deque message 4)confirm delivery
This intelligence would have to be built into whatever protocol and
client you use on the other side of the web socket.
SMTP has no provisions for "hold and serve on demand" email - that is
the typical task of an IMAP server.
Websocket is a new protocol to enable persistent, full-duplex,
efficient connections to web servers.
However, it is just HTTP, right ?
Because that's what web servers speak.
So how is it a "new protocol" ?
The big reason not to use IMAP is that it's not efficient for 5K+
concurrently connected clients.
Says who ? Have you tested this ?
The IMAP IDLE extension is implemented by any modern client and server,
and will push the message from the IMAP server to the client as soon as
it arrives; the only thing the client is responsible for is keeping the
connection open.
That sounds mighty close to what you are wanting to do.
I don't know if you are familiar with Microsoft's PUSH mail extension,
which works the same way: it keeps a persistent HTTP connection open
with long keepalive timeout values and will only reconnect once every X
minutes, thus keeping the TCP and HTTP overhead low.
Mail is then pushed to the client when it arrives.
I believe Dovecot implements a local delivery agent, so presumably
postfix contacts it via LMTP?
Postfix uses an internal protocol to deliver mail via its local(8) mail
delivery transport.
However, when an external command is used to deliver mail the RF822
message is piped to the command as-is; no encapsulating protocol is used.
Any substitute mail delivery agent must understand RFC822 format and may
accept optional variables that can influence delivery.
This is equally true for mailbox_command and a mailbox_transport
utilizing pipe(8).
LMTP, on the other hand, is an ESMTP-like protocol designed for local
transport of mail, but without a queueing mechanism.
It sounds like you DO need a queueing mechanism, in case the websocket
or its client is unable to accept the message right away - what if the
client is not connected?
I'm hoping LMTP doesn't mandate a distinct TCP connection to a server
for each message,
It supports streaming and pipelining just as SMTP does. but each
recipient is immediately accepted or permanently rejected.
vs. streaming messages over a single connection, otherwise the number
of concurrent connections would exceed what's practical.
There's a difference between the number and format of connections
between postfix and a delivery agent, and the number of connections made
by clients to a mailstore server.
Apart from using postfix directly to deliver mail to your websocket
application - which cannot use queueing if it doesn't implement either
SMTP or a mailstore - that is a backend problem, not a postfix one.
--
J.
