The reason for the double deliveries in the LMTP daemon is because the old insert_messages() function used to take lists of users to directly deliver. The new insert_messages() function takes a list of dsnuser structures, and expects that *either* the useridnr field is filled (for direct-to-useridnr delivery, which isn't supported by any of the frontends, but is supported in the lower layers ;-) or the address field, which is first checked as a username and then as an alias (this allows usernames in the form of '[EMAIL PROTECTED]' to operate without requiring an alias that says '[EMAIL PROTECTED] delivers to [EMAIL PROTECTED]').
Some refactoring might be necessary, because we need to inform the MTA whether or not its envelope recipients were valid before it will send us the message. This means users need to be validated before read_header(), which is a problem because at the moment this vaildation happens in insert_messages(). Fine and dandy in pipe land, where the MTA will send the message regardless of the disposition of the recipients, and only at the very end are error conditions returned as exit codes... in LMTP land we need to know ahead of time. I think what I'll do is move the user validation code from insert_messages() into dsn.c, perhaps calling it dsn_check_users() or dsn_prepare_deliveries(). Then, we'll have this order: For command-line and envelope-recipient deliveries: - receive addresses and store them into the dsnusers list. - dsn_prepare_deliveries() - if no deliveries are valid, return an error. - read_header() For deliver-to header deliveries: - mime_readheader() - mail_adr_list() - dsn_prepare_deliveries() - if no deliveries are valid, return an error. - insert_messages() Aaron
