At 12:34 PM 4/9/2005 -0600, Alan Maitland wrote:
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).
I think what you are saying is:
Spammer.tld sends a message to SpamTarget.tld claiming to be forwarded by
forwarding.tld.
domain.tld --> forwarding.tld --> SpamTarget.tld
^
Spammer.tld --> --> --> /
SpamTarget must authenticate forwarding.tld or Spammer can do whatever he
wants. The *only* piece of information that can be trusted by
SpamTarget.tld is the IP address in the TCP connection, and that won't
match the forwarder's IP address. *All* headers and *all* envelope
information can be faked.
Let me know if I misunderstood your scenario.
--
Dave
************************************************************ *
* David MacQuigg, PhD email: dmquigg-spf at yahoo.com * *
* IC Design Engineer phone: USA 520-721-4583 * * *
* Analog Design Methodologies * * *
* 9320 East Mikelyn Lane * * *
* VRS Consulting, P.C. Tucson, Arizona 85710 *
************************************************************ *