I'm realy sorry.
I've forgot to mention that Troyaned_user(_at_)Fast_Speed_DSL_Provider and
Fast_Speed_DSL are valid addresses.
They will pass SPF checks if server has SPF verification (but consider also
outdated servers without SPF)
Emails will be delivered to users at Delivery_Notification_Server's until
Troyaned IP will be blacklisted.
But also short notification messages with spam text in subject will be
delivered to our_real_target(_at_)domain(_dot_)tld
using _valid_ MTAs as origin after a while.
Messsages like:
--
From: somebody(_at_)Delivery_Notification_Server
Subject: Read: Enlarge it. Read more on
http://cheap.domain.we.buy.using.stolen.creditcard.com
Your message
To: Some Body
Cc:
Subject: Enlarge it. Read more on
http://cheap.domain.we.buy.using.stolen.creditcard.com
Sent: Sat, 10 Jul 2004 07:34:15 -0800
was read on Sat, 10 Jul 2004 12:22:48 -0800
---
This is unexpected. You will be unable to block them using any technology we
currently have :-(
Only using some tricky algo - "Do not accept notifications/bounces on emails
I've not send"
SPF unable to validate if address our_real_target(_at_)domain(_dot_)tld valid
for
notifications/reply-to/errors-to/return-path.
Even more - since there is exists server generated notifications/errors -
it's a must to have valid algo to prevent this.
Humans can not prevent this.
Is there any recomendations on validation addresses for
bounces/notifications ?
For example I would like to recomend all MTAs to check
bounches/notifications emails in the same as MAIL FROM and Sender.
But this can cause some problems with store-n-forward MTAs :-(
Even early checks on store-n-forward MTA can not prevent this.
Spammer can emulate store-n-forward server sending already stored emails to
users MTA and bounces/notifications will be generated to innocent users.
To prevent this store-n-forward MTAs must rewrite return-path/notifications
to own domains.
At the moment I believe that digital signature on mail headers are best
solution on spam problems.
We can force user to provide signatures for all emails he pretend to own.
Sign headers using all keys for address from Mail-From, Error-To,
Notifications-To
SPF is realy weak and will be bypassed by spammers easily :o(
--
Andriy G. Tereshchenko
TAG Software
Odessa, Ukraine
http://www.24.odessa.ua