SPF List,
Here is a scenario for which I would like some feedback regarding proper
SPF record publishing and SPF aware MTA processing behavior.
The scenario relates to that ugly issue of forwarding. I am hopeful that
the answer will be something like "but of course Alan, if SPF were being
appropriately implemented at the final receiving SMTP server this would
never be a problem...", so go ahead, make my day.
SCENARIO:
Published Records in sender's zone (presume IPs and zone are not malicious)
Domain: domain.tld
Published SPF TXT: v=spf1 include:forwarding.tld -all
Domain: forwarding.tld
Published SPF TXT: v=spf1 ip4:10.10.10.1 ip4:10.10.10.2 ip4:10.10.10.3
ip4:10.10.10.4 ip4:10.10.10.5 ip4:10.10.10.6 ip4:10.10.10.7 -all
Domain: Spammer.tld (presume IP and zone *are* malicious)
ip: 10.222.222.1
Domain: SpamTarget.tld (presume IP and zone are not malicious)
ip 10.111.111.1
A message is sent from Spammer.tld via 10.222.222.1 to SpamTarget.tld at
10.111.111.1 representing in its headers that the original message was
forwarded from a bogus user foo(_at_)domain(_dot_)tld passed from 10.10.10.4 (which
would be a valid SMTP server at domain.tld if the forwarding event had
actually taken place, because headers would be correct to the extent that
the forged header claims the originator was foo(_at_)domain(_dot_)tld from 10.10.10.4
(mail4.forwarding.tld) and 10.10.10.4 is an appropriate SMTP server for
mail sent by domain.tld).
From the final receiver's point of view at 10.111.111.1, they just
received a message which ultimately came from 10.10.10.4 originated by
foo(_at_)domain(_dot_)tld and checking IP and domain, they discover the domain and IP
of the original sender are valid (even though they are totally created by
the research and efforts of the intermediary forwarding spammer system
Spammer.tld 10.222.222.1).
In a non SPF world, such messages would be delivered and possibly bounced
back to the original victim of the identity theft.
Given the txt records listed above, if the final receiver's MTA implemented
SPF properly, would it be able to realize that domain.tld would not forward
via spammer.tld and thus would avoid making an attempt to deliver to a
local user at 10.111.111.1 and not bounce from their end back to 10.10.10.4?
If this is the case, then some recent activities by domain identity theft
spammers are now providing excellent reasons for all sites to quickly
migrate to SPF.
If not, is there a convenient way in SPF syntax to tell the final
10.111.111.1 user that no forwarders beyond the include: are ever used by
domain.tld?
List input on this scenario will be greatly appreciated. Yes, my company
is being specifically targeted for this kind of behavior. And now, with
the shiny new SPF / Spamhaus aware SMTP server software just purchased
(which so far is seemingly working out to be a true gem), we are seeing it
clearly, have evidence and want to act accordingly against the spammers
perpetrating this kind of activity.
As a related side note http://news.bbc.co.uk/2/hi/americas/4426949.stm is a
worthy read for such spammers.
Each participating Internet connected network has a right to filter what
they judge as spam (a cold war), but when spammers steal domain identities
in a clear and malicious attempt to cause harm to another's reputation (a
hot war), how much greater then should the punishment become?
Best,
Alan Maitland
WebMaster(_at_)Commerco(_dot_)Net
The Commerce Company - Making Commerce Simple(sm)
http://WWW.Commerco.Com/