On Tue, 12 Aug 2003, Jason R. Mastaler wrote: > Tim Rice <[EMAIL PROTECTED]> writes: > > > Some MTAs don't blindly accept the confirm message causing an error > > if there is a DNS problem or the user/domain is bogus which > > leaves the incoming message in the queue for retry later. > > Er, only MMDF you mean. As I explained in my last reply, there is a > workaround for every other MTA. > > > What if we scanned the pending queue for a duplicate message before > > trying to send a new confirm message. If it is a duplicate, remove > > the pending message just created and retry the confirm message > > for the original pending message. > > > > Perhaps keep a MD5 sum list of the messages in pending queue to make > > it easier to find duplicates. > > This seems like a whole lot of work for something that only affects > one TMDA user (you).
Only one because no one with MMDF would dare use TMDA in it's current form. It would require several hundred Megs of additional space for each user. > > In my last reply, I asked the following, and I'd still like to know if > you've pursused this: > > Is there no way to configure MMDF's SMTP interface to just accept the > transmission regardless, to get it into the mailq where it will be > retried as necessary? Now that I have taken the time to research this, I can say that there does not seem to be any way to do this short of rebuilding the mail subsystem from MMDF sources on sourceforge.net. -- Tim Rice Multitalents (707) 887-1469 [EMAIL PROTECTED] _________________________________________________ tmda-workers mailing list ([EMAIL PROTECTED]) http://tmda.net/lists/listinfo/tmda-workers
