An atmosphere where people only dare offer concrete answers to the literal question asked is one where programmers will not improve themselves. However if you allow people to try to help each other and improve themselves, then by definition they will try to offer wisdom. That wisdom may or may not be the literal answer originally requested. So which do you prefer? That people try to give the best advice that they can, or that people deliberately let others not improve?

Furthermore you seem to be missing basic cause and effect. To the extent that this is a shrine of elite programming gods (not very much, but bear with me) that is because the people who have been here for a while have done a lot of helping each other and improving themselves. Think about it. If interacting in this forum results in real improvement, then people here are going to become a lot better than average.

And let me explain why this matters. A big part of being a decent programmer is understanding the design of things well enough to select clean approaches to problems. And a large part of that is knowing what you should do yourself versus what should be delegated to someone (or something) else and why. Yes you can do that but you don't want to, and here is why.. is a useful response to someone who is trying to improve.

OK, so you aren't a server administrator. But you want to do something that is normally done by server administrators. Therefore you should learn something about the considerations that they have.

Finally you are mischaracterizing your answers. At the moment, here is what I see for your original question:

• An answer that says how you can do it in Perl, pointing out that it is a PITA to set up, and giving detailed instructions for how to do it in sendmail. (ie You got your answer, and a bit extra.)
• An answer that points out the problems caused by having extra bounces.
• A comment that says to read documentation for your MTA. In case it is not obvious to you, Abigail-II's answer refers to the fact that with many MTAs, users can write their own scripts to dynamically handle mail. Those scripts are often written in Perl, and your question didn't specify enough context to say whether or not that was the kind of script that you were writing. So despite talking about an MTA, this is a direct answer to what you might have meant.
• You got an explanation of why it is a bad design to send bounce messages from out of an MTA.
• You got pointed to Mail::Audit as well as a comment that you shouldn't be bouncing. Mail::Audit is meant to integrate into a mailserver and take care of the mechanics of sending the bounce etc for the programmer - in other words that is an answer.
• You got an explanation of why it is better to reject rather than bounce. Perhaps you don't care whether you are adding to the spam problem. But if you don't care about others, then why should anyone else care about you?

It's pretty simple to format a message similar to the following:

$msg = qq{From: Mailer-Daemon\@$your_domain
To: $supposed_sender_address
Subject: Undeliverable message

The message you sent on $date to $original_recipient could
not be delivered, as that user does not exist.

SMTP Error: 550, 5.1.0 unknown user
Host: $mail_server_dns [$mail_server_ip]
.
};
[download]

You can include whatever else you want in the message, up to and including insults to the sender's intelligence and heritage. You send this just as you'd send any other message, only in order to make it look more legitimate as a bounce, you'll want to make sure the headers and the error report show some relation where the machine addresses are concerned.

That's as close an answer to your questions as I can give based on my understanding of your problem, as explained by you.

The advice other monks have given regarding the usefulness of bouncing email stands, but if you want to send a bounce message, that's about all there is to it. I make no recommendations about whether or not to send bounce messages since you have been informed of the reasons for and against.

I do know that several people have taken their own time and expended their own effort to tell you both how to do this and why you may not want to do it. Soem of those answers involed doing it from Perl and other involved doing it through other, often better, means. For their time and effort, they have been greeted with hostility and insults instead of thanks and compliments. There is an oft-quoted (or at least it used to be oft-quoted) saying on comp.lang.perl.misc that goes like this:

"Get real! This is a discussion group, not a helpdesk. You post something, we discuss its implications. If the discussion happens to answer a question you've asked, that's incidental."
-- nobull@mail.com in clpm

• The SMTP destination address is the SMTP return address. The return address is usually available in the Return-Path header of the delivered message.
• The return address is the empty address; this is so double bounces get delivered to the postmaster of the mail server.
• The To address is the return address.
• The From address is usually MAILER-DAEMON at your domain.
• The format should follow the standard for error messages.
• Optionally, the original mail can be included as an attachment.

Doing all this without modules is hard because you need to parse the message to find the return address, generate the bounce messages possibly with attachments, and do the SMTP transactions.

...at first, I thought that maybe this was flame-bait.

It started out pretty funny, but then degenerated.

I don't agree that it's in character for us to transplant clpm sensibilities here. But I do have to agree with the consensus of response to this post.

Even if you're unable to comprehend the utility of the responses to your original question, it is civilized to acknowledge the effort that went into the answers.

And the truth is, even before this post, there were both answers and wisdom offered. What your response revealed (without you saying so) is that you simply didn't understand the responses.

Lashing out instead of asking for help and clarification is a good way to ensure that no one else will spend 20-40 minutes crafting (and sometimes even testing) a response for you.

...All the world looks like -well- all the world, when your hammer is Perl.
---v