Patch: support BURL
in [Postfix]
|
From: "Steve" on 9 Apr 2010 21:07 -------- Original-Nachricht -------- > Datum: Fri, 9 Apr 2010 20:51:03 -0400 (EDT) > Von: Wietse Venema <wietse(a)porcupine.org> > An: Postfix users <postfix-users(a)postfix.org> > Betreff: Re: Patch: support BURL > Reinaldo de Carvalho: > [ Charset ISO-8859-1 unsupported, converting... ] > > On Fri, Apr 9, 2010 at 8:48 PM, Wietse Venema <wietse(a)porcupine.org> > wrote: > > >> > > >> Mail client will write message to imap folder and MTA will get the > > >> message. Avoid send messahe twice over the link. > > >> > > >>-- > > >>Reinaldo de Carvalho > > >> > > > > > > Why is there a problem with sending mail to the SMTP server directly, > > > instead of taking an indirect route via an IMAP server? > > > > > > ? ? ? ?Wietse > > > > > > > IMAP users will benefit saving bandwidth ($/Kbyte) and time (in slow > > connections). > > That would not explain why sending to an IMAP server is > faster than sending that same message to an SMTP server. > It is not faster (I think). But is it not that way that if you send a mail from an IMAP client then the message gets transfered to the SMTP server and then the same sent message is again saved in the IMAP send folder? This results in sending the same data (+/-) twice. Once to the SMTP server for delivery and the second time to the IMAP server for saving it in the send folder (and maybe a third time when downloading the message body in the send folder to be chached by the IMAP client). As far as I understood that BURL thing it helping to only send the data once and the second data transfer is then done with BURL. > Wietse > // Steve -- GRATIS f�r alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
From: Reinaldo de Carvalho on 9 Apr 2010 21:35 On Fri, Apr 9, 2010 at 9:51 PM, Wietse Venema <wietse(a)porcupine.org> wrote: > Reinaldo de Carvalho: >> >> IMAP users will benefit saving bandwidth ($/Kbyte) and time (in slow >> connections). > > That would not explain why sending to an IMAP server is > faster than sending that same message to an SMTP server. > > Wietse > Send a unique message is faster than send twice (twice for saving on IMAP server). Mail client can save message in 'pending message' folder, connect with MTA and MTA read and send this message, than mail client move message to 'Sent' folder. Send a URI is faster* than download the message and send to MTA (forward) (partially useful, a matter of habit: forward the big message and if necessary sent another mail with some text). *assuming a slow connection between MUA and servers (but not between MTA and IMAP server). Some improvement on IMAP protocol to create a message from another and prepending a content should make BURL more useful. -- Reinaldo de Carvalho
From: Wietse Venema on 10 Apr 2010 09:19 Reinaldo etse:de Carvalho: > That would not explain why sending to an IMAP server is > faster than sending that same message to an SMTP server. Reinaldo de Carvalho: > Send a unique message is faster than send twice (twice for saving on > IMAP server). Saving to the IMAP server? So this is really about sending yourself mail via IMAP, instead of listing yourself in the Cc: address box. That saves no bandwidth - instead it reverses a single MTA->IMAP mail flow into IMAP->MTA, at the cost of another protocol. There are smarter ways to do this: teach the IMAP server how talk authenticated SMTP (it can proxy the user's credentials, just like the MTA can proxy them with BURL). Then, the IMAP server can manage the entire message composition process instead of relying on BURL kludges. Wietse
From: Reinaldo de Carvalho on 10 Apr 2010 12:34 On Sat, Apr 10, 2010 at 10:19 AM, Wietse Venema <wietse(a)porcupine.org> wrote: > Reinaldo de Carvalho: >> Send a unique message is faster than send twice (twice for saving on >> IMAP server). > > Saving to the IMAP server? > > So this is really about sending yourself mail via IMAP, instead of > listing yourself in the Cc: address box. > > That saves no bandwidth - instead it reverses a single MTA->IMAP > mail flow into IMAP->MTA, at the cost of another protocol. > > There are smarter ways to do this: teach the IMAP server how talk > authenticated SMTP (it can proxy the user's credentials, just like > the MTA can proxy them with BURL). Then, the IMAP server can manage > the entire message composition process instead of relying on BURL > kludges. > > Wietse > I agree. The background idea is improve comunication between MTA->IMAP or IMAP->MTA to avoid data retransmission, then BURL can't be the better approach, but it is what was standardized. -- Reinaldo de Carvalho
From: Mike Abbott on 12 Apr 2010 09:56
>> + if (in_stream == NULL) { >> + /* must fail the entire transaction */ >> + chat_reset(state, var_smtpd_hist_thrsh); >> + mail_reset(state); >> + rcpt_reset(state); >> + return -1; >> + } > > Why no response to the client? The function imap_open() responds to the client before it returns NULL. in_stream = imap_open(state, url); >> + case SMTP_ERR_EOF: >> + smtpd_chat_reply(state, "554 4.6.6 EOF from IMAP server"); >> + vstream_longjmp(state->client, SMTP_ERR_QUIET); >> + break; > > Why is the DSN code 4.X.X when the SMTP reply code is 5XX? Is this a > permanent or a transient error code? It is a transient failure. The reasoning for these particular codes was as follows. RFC 4468 section 3.2 states "If the URL fetch fails, the server will fail the entire transaction." RFC 5321 section 4.2.2 uses code 554 for "Transaction failed." And the table in RFC 5248 section 2.4 implies that a 4.6.6 is valid with a 554. If this interpretation of the RFCs is incorrect, please propose corrected response codes. The remainder of your feedback speaks to style and to weaknesses in the implementation that I pointed out in the cover letter to the code contribution. That cover letter also said: Feel free to [...] restructure or rewrite the code as desired, as long as you preserve our copyright. We understand that our implementation choices may differ from yours; if you see a better way to achieve the same goal please do adopt the better way. |