Objections to making the smtp mailer_t synchronous?

[Sam Roberts]

Bonsoir!

The smtp mailer doesn't deal with mail like:

To: address@hidden, address@hidden
Bcc: address@hidden, address@hidden

It just sends the message to all the addresses, making the
"blind" cc not particularly blind.

The correct algorithm is

- open smtp connection
- look as msg, figure out addrto&cc, and addrbcc
- deliver to the to & cc addresses:
  - if there are bcc addrs, remove the bcc field
  - send the message to to & cc addrs:
  mail from: me
  rcpt to: address@hidden
  rcpt to: address@hidden
  data
  ...

- deliver to the bcc addrs:

  for a in (bccaddrs)
  do
    - add header field to msg,  bcc: $a
    - send the msg:
    mail from: me
    rcpt to: $a
    data
    ...
  done

- quit smtp connection

Note: if ANY address fails, then you can close the connection, and none of
the messages will be delivered (my reading of 821, tested on my ISP).  This
is good, either the message is accepted by the MTA for delivery to everybody,
or to nobody. After acceptnce, if it has problems, it'll send DSNs back.

The RCPT_TO goto in smtp_send_message is bad enough as it is, I don't
want to have to do this for the above algorithm. I guess I could, but
I don't see the pain as worthwhile, since (unlike the pop and imap
code) I don't see asynchronous i/o as being useful.

We need non-blocking on reading of mailboxes, its an interactive
protocol, with complex returns. Sending a message isn't, the only return
is an error number. If you want non-blocking, you can fork,
call the mailer, and exit with the error code (can't do that with
a pop3 LIST command). If you have threads, one thread can
spin off and return the status code.

If there's some argument why people would need asynch i/o, I'll try,
but I'd rather not make a rats nest if not necessary.

Opinions?

Sam

-- 
Sam Roberts <address@hidden> (Vivez sans temps mort!)