sounds ok to me :)
Ilja
Aaron Stone wrote:
Working on it as we speak! Catch you in about an hour?
Aaron
Ilja Booij <[EMAIL PROTECTED]> said:
Hi,
Aaron Stone wrote:
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().
OK, that's clear
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()
I like the part where you say 'What I'll do' :)
Do you think this work will take long? I think we must really release
rc3 tomorrow (Friday, March 5th). This stuff really has to work if we
want to release.
Ilja
_______________________________________________
Dbmail-dev mailing list
Dbmail-dev@dbmail.org
http://twister.fastxs.net/mailman/listinfo/dbmail-dev
