On Fri, 2005-09-16 at 00:45 +0100, James Wilkinson wrote: > 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.) This is what is happening in the OP's case - the bounces are coming from AOL, which still has a lot of servers handling mail in an old-fashioned accept-then-bounce way. The good news is that AOL are working towards using a single-tier mail system that will stop their servers generating this backscatter (and have already significantly reduced it). > 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. True, which is why the best policy is to ensure that an incoming message is deliverable before accepting it. That way, you reject the message directly in the SMTP transaction and don't have to worry about generating bounces, to possibly forged addresses. Paul. -- Paul Howarth <paul@xxxxxxxxxxxx>
