[opensuse] Postfix and Procmail soft-bouce or autoreply
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 postmaster@official.domain.com. First of all, I'm having trouble trying to bounce messages to the sender, but still deliver them to the recipient. I figured I would treat the two deprecated domains as Local to the relay server, and deliver messages to procmail. Then have procmail send an autoreply to the sender and add a tag to the body and finally requeue the message for relay to the SMTP mail hub. I don't have any trouble sending the messages to procmail, but I can't get procmail to requeue the messages correctly. I have used Postfix in the past and feel comfortable with it's configuration, but I have very little procmail experience. It seems to be a VERY powerful tool that should be able to handle this task simply. I just don't know where to start as far as configuring my procmail recipies, or even if this postfix/procmail combo is even the best solution. Is it possible to do this using ONLY postfix? (I don't think postfix is able to add tags to the body of messages, OR send a bounce message and mail delivery at the same time.) Thanks for any help anyone can provide. ~Dale -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
* Dale Schuster
I don't have any trouble sending the messages to procmail, but I can't get procmail to requeue the messages correctly. I have used Postfix in the past and feel comfortable with it's configuration, but I have very little procmail experience. It seems to be a VERY powerful tool that should be able to handle this task simply. I just don't know where to start as far as configuring my procmail recipies, or even if this postfix/procmail combo is even the best solution.
List-Post: mailto:procmail@lists.RWTH-Aachen.DE
List-Subscribe:
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail,
mailto:procmail-request@lists.RWTH-Aachen.DE?subject=subscribe
List-Unsubscribe:
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail,
mailto:procmail-request@lists.RWTH-Aachen.DE?subject=unsubscribe
List-Archive: http://MailMan.RWTH-Aachen.DE/pipermail/procmail
List-Help: mailto:procmail-request@lists.RWTH-Aachen.DE?subject=help
List-Id: discussion of the procmail program
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Friday 2007-06-22 at 13:10 -0700, Dale Schuster wrote: ...
First of all, I'm having trouble trying to bounce messages to the sender, but still deliver them to the recipient. I figured I would treat the two deprecated domains as Local to the relay server, and deliver messages to procmail. Then have procmail send an autoreply to the sender and add a tag to the body and finally requeue the message for relay to the SMTP mail hub.
I don't have any trouble sending the messages to procmail, but I can't get procmail to requeue the messages correctly. I have used Postfix in the past and feel comfortable with it's configuration, but I have very little procmail experience. It seems to be a VERY powerful tool that should be able to handle this task simply. I just don't know where to start as far as configuring my procmail recipies, or even if this postfix/procmail combo is even the best solution. Is it possible to do this using ONLY postfix? (I don't think postfix is able to add tags to the body of messages, OR send a bounce message and mail delivery at the same time.)
You could bounce a "vacation" message, which doesn't stop the mail from proceeding. I mean, use the vacation program. It has other advantages, as only bouncing once a week, but it doesn't add tags to the email as you want. Procmail could possibly do what you want, I think. But the forwarding part... I'm not sure how to know the proper new destination address. Plus, procmail would probably receive and process all local email. Postfix also has a "relocated" table, but it will just bounce a message, I think. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFGfDFetTMYHG2NR9URAozcAJ4gQ+sEA5AzwXkR9PMvAzOyVw9eLACeLsCS 7DFGq3GglHhzho5J4Q0Mh7I= =9M+6 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
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 postmaster@official.domain.com.
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: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Sandy Drobic
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
That is exactly why I'm red in the face and my forehead hurts from banging the wall. 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.
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
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
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. problem 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: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Friday 2007-06-22 at 16:10 -0700, Dale Schuster wrote: ...
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.
The subject can be modified using formail, I think, and it can be fired from procmail.
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.
You don't need the relocation message to give the new address directly: you define the exact message. Which I don't have clear is how big it can be: I think it is a single line, perhaps long. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFGfGEitTMYHG2NR9URAlXlAJ4r2BfEcuxL2fPy8uwqMI8jNMK8pACgkFDy by9xH781XD/Iqj3T1DthY0U= =h5wb -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Carlos E. R. wrote:
The Friday 2007-06-22 at 16:10 -0700, Dale Schuster wrote:
...
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.
The subject can be modified using formail, I think, and it can be fired from procmail.
Yes, that is probably the easiest way.
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.
You don't need the relocation message to give the new address directly: you define the exact message. Which I don't have clear is how big it can be: I think it is a single line, perhaps long.
No, if you use relocated the text is already hardcoded, you can't change it. It's another situation alltogether if you simply reject the mail and add the explanatory text as reject message. That line can be pretty long, long enough to inform the sender and give a link to a more detailed web page. smtpd_recipient_restrictions = reject_non_fqdn_recipient, reject_non_fqdn_sender, permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination # ... some more spam checks check_recipient_access hash:/etc/postfix/domain_deprecated /etc/postfix/domain_deprecated: example.com reject Mails for example.com will no longer be accepted, please visit http://example.com/domain_deprecated.html for details The line after reject should be a single line. -- Sandy List replies only please! Please address PMs to: news-reply2 (@) japantest (.) homelinux (.) com -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Saturday 2007-06-23 at 11:06 +0200, Sandy Drobic wrote:
You don't need the relocation message to give the new address directly: you define the exact message. Which I don't have clear is how big it can be: I think it is a single line, perhaps long.
No, if you use relocated the text is already hardcoded, you can't change it. It's another situation alltogether if you simply reject the mail and add the explanatory text as reject message. That line can be pretty long, long enough to inform the sender and give a link to a more detailed web page.
Are you sure? Postfix man pages are not the easiest to read, but "man relocated" seems to say different: ] The input format for the postmap(1) command is as follows: ] ] · An entry has one of the following form: ] pattern new_location ] Where new_location specifies contact information such as an ] email address, or perhaps a street address or telephone ] number. ] ] · Empty lines and whitespace-only lines are ignored, as are lines ] whose first non-whitespace character is a `#'. ] ] · A logical line starts with non-whitespace text. A line that ] starts with whitespace continues a logical line. So I understand you can use: someone@oldaddress The address you have used is no longer valid, please phone me at (+34) 555 1234 Now, the message will probably contain more text, and that I guess will be hardcoded. However... I think I read somewhere that this messages could be translated, for instance, to Spanish. But I don't remember where I read this. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFGfPQstTMYHG2NR9URAtgjAKCAlp0+iIkNDP1ettiaMC68w9VD0ACfTNxg jIEbAEhMiAU/RlteB8445Kk= =t+Fi -----END PGP SIGNATURE-----
Carlos E. R. wrote:
The Saturday 2007-06-23 at 11:06 +0200, Sandy Drobic wrote:
You don't need the relocation message to give the new address directly: you define the exact message. Which I don't have clear is how big it can be: I think it is a single line, perhaps long.
No, if you use relocated the text is already hardcoded, you can't change it. It's another situation alltogether if you simply reject the mail and add the explanatory text as reject message. That line can be pretty long, long enough to inform the sender and give a link to a more detailed web page.
Are you sure? Postfix man pages are not the easiest to read, but "man relocated" seems to say different:
So I understand you can use:
someone@oldaddress The address you have used is no longer valid, please phone me at (+34) 555 1234
Yes, that much is true, but...
Now, the message will probably contain more text, and that I guess will be hardcoded. However... I think I read somewhere that this messages could be translated, for instance, to Spanish. But I don't remember where I read this.
The entire reject text would read like this:
550 5.1.1
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Saturday 2007-06-23 at 12:38 +0200, Sandy Drobic wrote: ...
The entire reject text would read like this:
550 5.1.1
: Recipient address rejected: User has moved to The address you have used is no longer valid, please phone me at (+34) 555 1234
Ouch.
The part with the "has moved to" is hardcoded which makes it a bit tricky to use for anything else but another email address without sounding a bit strange.
Yep... Something like: someone@oldaddress another adress; please phone me at (+34) 555 1234 Possible, but not flexible. And very tricky if you want to use several languages. Multilanguage support in bounces messages is not implemented, and this causes many problems for plain users. (for instance, a header in all mails specifiying language could be used to generate bounces in the user's language)
This message is not configurable. Starting with Postfix 2.3 you can customize the bounce_template_file, but not this reject message.
Pity. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFGfP3LtTMYHG2NR9URAp2eAJ9KJUCypKnWndgNVqdMtktkJ3KWlQCgjlbw Dhn3XR7T4NXW/mDk/uNKumA= =QXLX -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Sat, 23 Jun 2007, by robin.listas@telefonica.net:
The Friday 2007-06-22 at 16:10 -0700, Dale Schuster wrote:
...
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.
The subject can be modified using formail, I think, and it can be fired from procmail.
Or with Postfix's body_checks(5) REPLACE and PREPEND functions. Theo -- Theo v. Werkhoven Registered Linux user# 99872 http://counter.li.org ICBM 52 13 26N , 4 29 47E. + ICQ: 277217131 SUSE 10.2 + Jabber: muadib@jabber.xs4all.nl Kernel 2.6.18 + See headers for PGP/GPG info. Claimer: any email I receive will become my property. Disclaimers do not apply. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Saturday 2007-06-23 at 11:30 +0200, Theo v. Werkhoven wrote:
The subject can be modified using formail, I think, and it can be fired from procmail.
Or with Postfix's body_checks(5) REPLACE and PREPEND functions.
Ah? Interesting... - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFGfPYCtTMYHG2NR9URAhLXAJ9112HUmVAhAz+StPXWQ8HXBBdt3gCghyp/ IkHg2mj6RffTOfpiMzjUdTc= =86yG -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Theo v. Werkhoven wrote:
Sat, 23 Jun 2007, by robin.listas@telefonica.net:
The Friday 2007-06-22 at 16:10 -0700, Dale Schuster wrote:
...
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. The subject can be modified using formail, I think, and it can be fired from procmail.
Or with Postfix's body_checks(5) REPLACE and PREPEND functions.
The problem is that you can not restrict these checks to only certain mails. The are applied to all mails. -- Sandy List replies only please! Please address PMs to: news-reply2 (@) japantest (.) homelinux (.) com -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Sat, 23 Jun 2007, by suse-linux-e@japantest.homelinux.com:
Theo v. Werkhoven wrote:
Sat, 23 Jun 2007, by robin.listas@telefonica.net:
The Friday 2007-06-22 at 16:10 -0700, Dale Schuster wrote:
...
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. The subject can be modified using formail, I think, and it can be fired from procmail.
Or with Postfix's body_checks(5) REPLACE and PREPEND functions.
The problem is that you can not restrict these checks to only certain mails. The are applied to all mails.
True Theo -- Theo v. Werkhoven Registered Linux user# 99872 http://counter.li.org ICBM 52 13 26N , 4 29 47E. + ICQ: 277217131 SUSE 10.2 + Jabber: muadib@jabber.xs4all.nl Kernel 2.6.18 + See headers for PGP/GPG info. Claimer: any email I receive will become my property. Disclaimers do not apply. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Theo v. Werkhoven wrote:
Sat, 23 Jun 2007, by suse-linux-e@japantest.homelinux.com:
Theo v. Werkhoven wrote:
Sat, 23 Jun 2007, by robin.listas@telefonica.net:
The Friday 2007-06-22 at 16:10 -0700, Dale Schuster wrote:
...
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. The subject can be modified using formail, I think, and it can be fired from procmail. Or with Postfix's body_checks(5) REPLACE and PREPEND functions. The problem is that you can not restrict these checks to only certain mails. The are applied to all mails.
True
It is possible to restrict header/body_checks to only certain mails, but you have to jump through some hoops to get that. I don't think it is worth the additional complexity, since there are tools better suited for the task. You would either need to set up a second instance (not just another listener) of Postfix or you have to deal with multiple cleanup processes, with different header/body_checks and assign them to the listeners in question. The last one is a bit tricky to keep track of, so I wouldn't recommend it. -- Sandy List replies only please! Please address PMs to: news-reply2 (@) japantest (.) homelinux (.) com -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Friday 22 June 2007 16:10, Dale Schuster wrote:
This is a source of confusion for me too. I'm not exactly sure where to look to accomplish Subject Rewrites. ...
It may not suit your other needs, but KMail filter actions can rewrite headers. Randall Schulz -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Randall R Schulz wrote:
On Friday 22 June 2007 16:10, Dale Schuster wrote:
This is a source of confusion for me too. I'm not exactly sure where to look to accomplish Subject Rewrites. ...
It may not suit your other needs, but KMail filter actions can rewrite headers.
KMail is a user program, but here a server implementation is required. Procmail can do most of that. Otherwise he needs a script that will perform the neccessary operations. -- Sandy List replies only please! Please address PMs to: news-reply2 (@) japantest (.) homelinux (.) com -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Dale Schuster wrote:
Sandy Drobic
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.
I feel for you, I was stuck in similar situations more than once. (^-^)
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.
Yes, the concept as it is must not be used.
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.
Additionally it won't hurt as much if spam comes in since vacation only sends a single mail to any sender within a week.
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.
The easiest way would probably to set up a procmail solution for that task. It should be done after content_filter. - check if spamlevel is not high, otherwise don't send to vacation - rewrite subject If you need to do more you will have to write a simple filter script that handles the rewrites and lookups you need. -- Sandy List replies only please! Please address PMs to: news-reply2 (@) japantest (.) homelinux (.) com -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Saturday 2007-06-23 at 00:51 +0200, Sandy Drobic wrote: ...
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.
Which reminds me that amavis-new and/or fetchmail sometimes can bounce messages in full or partially. And reminds me that I have to check and verify this. However... bounce messages with full headers are sometimes very useful, for instance, to learn which is the subscribed address to this list that is bouncing. There are some bouncers I have seen that do not copy even the subject line, nor the sended-to 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. :-/
And I'm keeping it for reference material ;-) - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFGfF6ttTMYHG2NR9URAsYOAJ97yG+flQJ5LSRvYua1u5PPATFv7wCdFgZ5 8KjBcP294a/8EsJyRob2wpQ= =ME3i -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Carlos E. R. wrote:
The Saturday 2007-06-23 at 00:51 +0200, Sandy Drobic wrote:
...
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.
Which reminds me that amavis-new and/or fetchmail sometimes can bounce messages in full or partially. And reminds me that I have to check and verify this.
However... bounce messages with full headers are sometimes very useful, for instance, to learn which is the subscribed address to this list that is bouncing. There are some bouncers I have seen that do not copy even the subject line, nor the sended-to address.
Unfortunately there are a lot of broken bouncers out there. As a general rule I don't mind if messages from my internal users bounce. They are authenticated, exist and want to receive bounces. But I do my very best to only accept mails that I can also deliver. -- Sandy List replies only please! Please address PMs to: news-reply2 (@) japantest (.) homelinux (.) com -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
participants (6)
-
Carlos E. R.
-
Dale Schuster
-
Patrick Shanahan
-
Randall R Schulz
-
Sandy Drobic
-
Theo v. Werkhoven