...

...

...

...

"claw" == <claw@kanga.nu> writes:

>> I would like to basically know how to delete the mail queue
>> messages sometimes if I know there is going to be a lot of
>> queued mail that I don't want delivered.

claw> IIRC (can't check now) it is stored inside the config.db for
claw> the list.  Removing that mail is a question of unpickling
claw> the DB and removing the approriate records.

Actually, I don't think so. I think those queued messages are just gleaned from the file system.

claw> <<An area that could stand some improvement FWLIW>>

And in fact, all this has changed in my current codebase. There's no queueing going on. I have two delivery modules, one that pipes to the command line interface of sendmail, the other which does direct smtp delivery to the local smtpd. This latter only handles error codes >= 500 (permanent errors), in which case it'll register a bounce to that addr just as if a bounce message was received.

However, at least with Postfix, it appears that you never get error reports for non-local addrs. The dialog with the local smtpd seems nearly asynchronous, which is actually a good thing. If Postfix can't deliver the message, it'll generate a bounce message for it (more on this in another follow up).

I believe this all works differently if the MTA supports DSN (delivery status notification), which sendmail does, but postfix does not. In that case, if you enable DSN, delivery becomes synchronous, and you do end up getting error codes back for failures. The problem with the synchronous deliveries is that you can't keep list object locked while that happens.

I'm beginning to think it's best not to do DSN and just improve the bounce detection, or do the VERP-like approach discussed earlier.

I think Dragon has said that he's got a better bulk mailer implementation that he's been using for a while. I think he's talked about porting it to the new delivery pipeline code, which would be cool to have as an alternative approach.

-Barry