Hi there. I've looked at the FAQ, and searched the archives, but can't find a good answer to this.
First, the basic question - why can't the "release" action, whether from tmda-pending or from an incoming confirmation, simply deliver the queued message to the DELIVERY maildrop? Why does it rely on resending the message though sendmail/SMTP? Doesn't the "accept" path through TMDA deliver it directly to the maildrop? Why not use that path? The reason I ask relates to the more complicated question. I have a local MTA (qmail) accepting messages from several forwarded accounts. However, crackdowns on dynamic IP ranges have forced me into using my ISP's server (verizon) for outgoing mail. So I used msmtp previously, and then switched to TMDA's internal SMTPHOST support when I started using TMDA. Now, the rub - my ISP does checking on the From header (or sender envelope? not sure) to see if I'm trying to send mail as some other verizon user. It refuses to accept the message if I appear to be spoofing as another verizon user. Granted, this is dumb (as it doesn't reject "[EMAIL PROTECTED]" as the From field), but how am I supposed to work around it? If someone sends me email from a verizon.net account, and they're not in my whitelist, it creates this nasty mail tornado where tmda keeps trying to relase the message when the confirm, verizon rejects it, but tmda still sends a "message delivered" update to the other verizon user. I got an angry mail from a verizon user saying he got like 50 of these over 24 hours after confirming his message. I'd like to hear suggestions for a better way of setting up qmail/sendmail under these constraints, if you have them. Thanks, Joe _____________________________________________ tmda-users mailing list ([EMAIL PROTECTED]) http://tmda.net/lists/listinfo/tmda-users
