Michael Häusler <[EMAIL PROTECTED]> said: > dsn.c:dsnuser_worstcase_list(...) should return the worst case. With the > current solution, if there are two deliveries (A with DSN_CLASS_OK and B > with DSN_CLASS_FAIL), there will be no delivery to A because of the > failure with B. Maybe a better solution would be to make > pipe.c:insert_messages(...) respect the individual status of the entries > of dsnusers?
The delivery to A is not thrown away, but may be duplicated when the MTA retries B. > It seems to me that insert_messages currently ignores (even > overwrites) the dsn classes, which are computed in > dsn.c:dsnuser_resolve_list(..). This is correct; the status is changed in the event of an error or over-quota situation. Lots of people have been saying that over-quota should do a full bounce, and I think we should look into that after 2.0.1. > Btw.: dsnuser_worstcase_list does not always return the worst case: if > one delivery results in DSN_CLASS_TEMP and another in DSN_CLASS_FAIL it > returns DSN_CLASS_TEMP. I don't know if this may cause problems anywhere. In a way, "worstcase" is a misnomer. It's trying to find one reasonable code to give to the MTA to ensure maximum proper mail delivery. If someone has a TEMP situation, and we tell the MTA it was FAIL, the mail doesn't get retried. On the other hand, the sender knows that there's something wrong right away. We're going to have to revisit this, and I think the people who are saying that my thinking is wrong are right and we should change the behavior. Aaron
