🚀 go-pugleaf

Feico <feicorem0veth1s@gmx.net> wrote:

>On Tue, 01 Jun 2004 22:01:57 +0100, Alan Bellingham <alanb@episys.com> wrote in
>borland.public.cppbuilder.nativeapi:
>
>>>    2a. Send a reply, such as
>>>         You sent mail to a nonexistant address
>>>          It appears that your message is spam. Please resend if you are human.
>>>         Your message has been received and will soon be replied to
>
>>Never do that - it merely causes the spam to be redirected to another
>>user. (Hint: spammers are liars. They do not put their own addresses on
>>emails. If you think it's spam, then it probably is, and the innocent
>>person whose name has been forged will be being spammed by you.)
>
>That's not an answer to my question, but all right.
>
>I agree that the first message (Mailwasher style) is not useful, unless it's from former friend who
>tries to stalk me.

Probable spam. Therefore the sending address is false. But the sending
address may actually exist, in which case you are sending unsolicited
bulk email to it.

>The second message is honest. If the sender is a spammer, he will probably not receive it (that's
>good), and if the sender is a friend who uses a bad program so that his message appears as spam, he
>will know it.

If spam, then the sending address is false. But the sending address may
actually exist, in which case you are sending unsolicited bulk email to
it.

>The third message is just honest. It will only be sent when the incomaing mesage has not been
>recognised as spam.

I've no problems with this.

I _do_ have problems with idiots running programs which send me email,
email that I didn't ask for, bulk email, because their programs naively
think that viruses and spammers actually put the originating addresses
on. This is why I'm raising a red flag at this stage.

The best definition of spam I know is Unsolicited Bulk Email - UBE.
These programs do that.

Unfortunately, by the time the email has been received by your ISP and
stored in the post box, it's too late, _way_ too late, to do the most
useful things (rejecting (not bouncing) anything from hijacked net
space, from known spammers, from open proxies, etc etc).

You'll need to read up on socket programming. You'll also need to read
up the relevant RFCs (2821 is probably most important, if my memory is
correct). Go to http://www.ietf.org/rfc.html for information though.

Alan Bellingham
-- 
ACCU Conference 2005 - 20-23 April, Randolph Hotel, Oxford, UK