John Keown wrote:
That is why and where smtp authentication comes into play. With smtp
authentication the hijacker cannot authenticate and therefore cannot send
from example.com return address.
That depends on the nature of the vulnerability exploited by the spammer.
For instance, consider http://dsbl.org/message?17970980
In this example, a Yahoo! customer set up a mail server (Proxy+) on his/her
own machine, which was configured to connect to Yahoo!'s SMTP mail relays,
authenticate to that relay as the customer and then relay out the mail.
Unfortunately the Yahoo! customer did not secure their own mail server, so
they became the input point of a two-stage open relay. That got the Yahoo!
mail server listed on dsbl.org's multihop relay list, and in fact it is still
listed there today.
Now in this case a look at the headers shows fairly clearly what happened, so
the blame clearly lies with the Yahoo! customer and not with Yahoo!
themselves, nor with any other example.com that might also be trying to relay
mail through the Yahoo! mail servers. However, someone not familiar with
reading headers might blame the purported sender, particularly if the SPF
check passed. And it's quite conceivable that other systems might not log
quite as much useful information in the headers to show what had happened.
Regards, Paul.