I've got to the stage now where messages can come in to any of my email addresses (barring my hotmail one) and they will make it all the way through to the TMDA filter. The TMDA filter is responding to those messages with a confirmation message which correctly goes back to the sender.
The problem I'm having is that since I'm having to use my own SMTP server to do mail delivery now (there being no mail service with the broadband connection I have), I have to fake my reply-to: stuff in the emails, since someone trying to reply to a mail apparently from "[EMAIL PROTECTED]" isn't going to have much luck :) So the fake "Reply-To:" has to have a real email address in it, in the diagram below, a reply I send to email that I received on any of my email accounts, always looks like it's been replied to by [EMAIL PROTECTED] The issue then seems to be, that TMDA likes to see it's confirmation messages replied to to the same address the original email was sent to, otherwise it treats the reply to the confirmation message, as a totally new email, which *also* requires confirmation. Check this out : (since this diagram will get broken cos it's too wide, you can see it at : http://www.godeater.homelinux.net/email.html in all it's unbroken glory! ) +-------+ | ISP 1 |___ +-------+ \ \ +-------+ \ | ISP 2 |_____ \ +-------+ \ \ \ \ Inbound email flows to TMDA +--------+ +-------+ +-----------+ +-------+ +----------+ +------+ | Sender |-->| ISP 3 |-->| fetchmail |-->| qmail |-->| procmail |-->| TMDA | +--------+ +-------+ +-----------+ +-------+ +----------+ +------+ | / / | ^ | | +-------+ / / | | V ^ | ISP 4 |----/ / V | Confirmation mail | | +-------+ / | |----------<-------------| | / | goes from TMDA back | +-------+ / | to qmail ^ | ISP 5 |--/ | | +-------+ V | | |---------<---------<--------<----------| qmail sends confirmation mail as though it had come from ISP 5 mail address qmail does sending of mail to outside world, and local delivery only, it has no fixed outside IP address, and no DNS record (well, not one that would make sense on the internet anyway). fetchmail is re-writing the recipient information on it's way into qmail as [EMAIL PROTECTED] - so this is currently the recipient information being used by TMDA. I've set CONFIRM_ADDRESS to one of my valid email addresses, at isp5.com. I've *tried* to use RECIPIENT_HEADER, but I can't seem to make it work. Presumably this is because I'm using it wrong, my assumptions were that : 1) I needed a RECIPIENT_HEADER somewhere in the confirmation email that would match the RECIPIENT_HEADER from the original email? 2) Since there wasn't one provided that would suit this role, I tried using formail as hinted at in the the config variables bit of the TMDA site, to add an "X-Originally-To:" header with the email address the message was sent to. The inbound email now arrives in the tmda-pending queue with this info on it, but the confirmation message doesn't put have it in it's own headers - should it? So it's also lacking from the reply to the confirmation. This results in the following sequence of events : 1) Sender writes to [EMAIL PROTECTED] 2) TMDA replies to sender, but the message is marked as Reply-To:[EMAIL PROTECTED] 3) Sender replies to confirmation message 4) TMDA sees it's not addressed to the isp3.com address and asks for confirmation again instead of releasing the original message. How do I get round this ? Is it possible to get fetchmail / qmail to deliver the messages with the real recipient info still intact? Bryan Childs _____________________________________________ tmda-users mailing list ([EMAIL PROTECTED]) http://tmda.net/lists/listinfo/tmda-users
