Chris Wright wrote: > That appears to be a SPAMMER who is faking a user ID at your domain in the > from address. > The dumb mail server of some of the recipients hasn't worked out that the > headers are forged, so it is returning the 'unknown address error' back to > you instead of the source. > What it should do is look at the headers to see that it is faked, and just > bin it without doing nothing. Guy Fraser wrote: > ...snip... > Mail servers do not generally accept a DATA command if the RCPT > command produces an error, so the rest of the headers are not > looked at. The proper response is to respond with a user > undeliverable error. That assumes that the receiving server knows that the address is unknown. Very often (as with westexe.demon.co.uk), the MX (server to which e-mails get sent initially) is owned by a big ISP (in my case Demon Internet), which doesn't know which addresses on westexe.demon.co.uk are valid. So it has to accept all e-mails to westexe.demon.co.uk. In this case, the relevant standards (RFC 821 and 2821) say that since the e-mail has been accepted but can't be delivered, a bounce message *must* be sent. (These days, there's enough spam and viruses about that this is no longer considered best practice.) In general, it's not easy to program a MTA to be sufficiently sure that an e-mail *is* faked that it can drop it. James. -- E-mail address: james | "I don't think so," said René Descartes. Just then, @westexe.demon.co.uk | he vanished.
