Hi Andrew,
AGT> Emails will be delivered to users at
AGT> Delivery_Notification_Server's until Troyaned IP will be
AGT> blacklisted.
Wrong - Trojaned IP is not the MTA (if it *was* - then SPF would
fail), and not only this, you already said it's a "valid SPF IP", so
you mean to say that it's the ISP's MTA - which will never get
blacklisted either. You're example needs more thought I think.
AGT> But also short notification messages with spam text in subject
AGT> will be delivered to our_real_target(_at_)domain(_dot_)tld using _valid_
AGT> MTAs as origin after a while.
Have you tested this? The RFC's state that DSN notifications should
back to the envelope sender (not to some other random place)
AGT> was read on Sat, 10 Jul 2004 12:22:48 -0800
That's an MDN - not a DSN - and is generated when a user clicks "Yes I
want to tell the sender that I read the email" - which they won't ever
do (for the few souls left who actually have this turned on still)
AGT> At the moment I believe that digital signature on mail headers
AGT> are best solution on spam problems.
You clearly have not thought this through then!
AGT> We can force user to
No - you can never force anyone to do anything. If you try to force
them then everyone else will "force you to stop" (by blacklisting
your products or suing you for loosing their legit emails or whatever)
AGT> SPF is realy weak and will be bypassed by spammers easily :o(
How many times do we have to tell everyone the same thing:-
SPF IS NOT AN ANTISPAM TECHNOLOGY
NOT NOT NOT NOT NOT NOT NOT.
It's an authentication mechanism, which happens to be very useful
for helping with spam problems - but it's NOT an anti-spam
technology.
The biggest help SPF gives us all is that it allows people to
reject emails in such a way as the (verified real) sender knows
the rejection took place (MTA 550), so nobody has to delve through
spam folders for missing emails, and no sender has to wonder why
they've got no reply yet.
Kind Regards,
Chris Drake