Dale Schuster wrote: > I am having a hard time conceptualizing a solution to this project. I am > using a postfix SMTP server to relay mail for three separate domains. This > server will be the entry point to our network and should relay messages > addressed to "<anyone>@official.domain.com" to another SMTP mail hub for > delivery. It should also collect e-mail addressed to two other deprecated > domains, notify the sender that the domain name has changed, and also > deliver the message to the same SMTP mail hub for delivery. The delivered > messages should include a tag in the body informing the recipient that > this message was addressed to the old (soon-to-be invalid) address. The > message bounced back to the sender should NOT contain the new address or > domain name, but a generic message to contact > [EMAIL PROTECTED]
After reading this I can understand very well just why you have trouble: the requirements are more than a bit weird and don't mesh well with common sense and current SMTP practise. Let's have a look what can be done easily, not so easy and what definitely should NOT be done. Relaying all mail from official.domain.com to another host is no trouble. The next part of the requirements shows a strange opinion how SMTP should work. I mean the part about accepting and bouncing the mail. You either accept the mail and deliver it or you do not accept it and the sending client has the duty to bounce the mail back as undeliverable. Any other behaviour is not covered by the RFCs (it can be done if you misconfigure your server bad enough). Once you accept the mail you assume the responsibility for it. You could of course deliver the mail to the intended recipient and send back a copy of the mail to the sender. Technically that is no problem. You simply set up a transport for that domain where a script takes care to send back a copy to the sender. But I can't for the life of me make sense of this. If you accept the mail the user does not need to look for another email address where he should rather send the mail to. This will not change as long as you accept the mail. On the other hand, the sender already has the mail (he sent it in the first place, so why should he need another copy of it back?). Just imagine if I send you a mail with 100 mb pdf files as attachment. I would not be happy to receive them all back just to be informed that I should contact a certain address. Now, lets think about the most common mail that will likely end up in that situation: yes, I am talking about spam and viruses. (^-^) They always falsify the sender address. So if you send back a copy of the mail, you will turn into an excellent backscatter source. All of this only points to one viable solution: do NOT send back the original mail, only a notification with the message that will inform the sender of the that the domain will not be available soon and how to contact someone for more information. Use vacation for that as Carlos has already told you. No need to send a notice for every single mail that arrives. That would border on harassment if someone is a busy mailer. (^-^) Another point is that the occasional spam will not make you flood the sender with useless notifications. Yes, vacation is a very good idea. The next part is the "tag the body to notify the recipient". As long as the recipient is not rewritten to another name he should see the address that the sender used without problem. To make it more obvious you could better add a tag to the subject line. The recipient would see the problem immediately once he opens his inbox. The other problem is, that the manipulation of the body will destroy the validity of all signed mails. And to make it a bit more challenging, the tagging program also needs to be mime-aware, otherwise it might insert a plain text tag into a html mail at the wrong part or even destroy an attachment or inline picture/document. Once you retire the deprecated domains you can use either relocated to tell the sender what the new address is or set up a simple check that rejects the mail and uses the reject text to inform the sender what the situation is. Commonly you use it to refer to a web page where the sender can read more details and maybe send a response to the postmaster or whatever. relocated is coupled with recipient validation and will be evaluated at the same place in the order of restrictions. Either at the end of smtpd_recipient_restrictions or when you explicitely use reject_unlisted_recipient. What you can also do is to use some simple scripts to grep the log and build a report for the recipient to inform him which senders have been blocked that tried to contact him at the old retired address. Phew, I just realised that I wrote half an essay here in response. I hope it helps you with your pointy-haired bosses who set up the strange requirements in the first place. :-/ -- Sandy List replies only please! Please address PMs to: news-reply2 (@) japantest (.) homelinux (.) com -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
