Sandy Drobic <[EMAIL PROTECTED]> wrote on 06/22/2007 03:51:41 PM: > 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.
That is exactly why I'm red in the face and my forehead hurts from banging the wall. > 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. That I have working flawlessly already. Thanks. > 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). This has been my biggest argument to the "pointy haired's". > 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. I even contemplated adding an additional mailhop relay whose sole task would be formatting bounce messages. But then I reconsidered. > 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. I really don't want to send the original message back to the sender, only send an informational message which can easily be done with "Vacation" as you and others have pointed out. > 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. This is a source of confusion for me too. I'm not exactly sure where to look to accomplish Subject Rewrites. I think that may be a suitable compromise, but my requirements are specifically to add a tag in the message. Thank you for the ammunition I needed for arguing further. > 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. Initially I was trying to use a relocated map from postfix, but I don't want to broadcast what the new addresses are. > 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. :-/ > Thank you for your detailed response. It is very helpful. ~Dale -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
