David Mazieres wrote:
Not necessarily. I know people who send mail directly from their
laptops, without relaying through a trusted host. I don't necessarily
think this is a good idea. However, someone who reads the SPF spec is
entitled to believe this is reasonable to do in conjunction with a
"v=spf1 ?all" SPF record.
I see your valid point, but the LAPTOP or better labeled, any MUA, would use
the RFC required FQDN, domain literal or as its often the broken case with
MS software, uses the netbios local computer name. no?
It should never use the email domain for the client machine domain. That
could not happen unless it was malicious, intentional and/or broken
software.
If the MUA uses standard software (or broken MS software with netbios
names), the machine domain should not equal the email domain. Understand?
Examples:
#1: A good RFC client software machine, DYNAMIC IP based, using my current
home Bellsouth connection as an example:
HELO adsl-146-15-110.mia.bellsouth.net
MAIL FROM: xxxxx @ bellsouth.net
or using domain literal:
HELO [70.146.15.110]
MAIL FROM: xxxxx @ bellsouth.net
#2: A good but technically broken MS outlook client machine, DYNAMIC IP
based, using my current Bellsouth connection as an example:
HELO hdev1 <---- netbios name of my local machine
MAIL FROM: xxxxx @ bellsouth.net
#3: It should never be this. This would violate RFC 2821 and SPF.
HELO bellsouth.net
MAIL FROM: xxxxx @ bellsouth.net
Right? Does this make sense?
Now, it could be possible that I am the good person doing this, but it means
my software is seriously broken and not following any specification. In the
eyes of the remote, with an SPF consideration, it should fail this unless
there is a PASS.
I wish the SPF language had an "equals" mechanism that let you compare
the expansion of macros. For example, it would be nice to be able to
publish an SPF record like this:
v=spf1 ptr -equals:%{o}:%{h} ?all
Basically saying that if the ptr check fails, then Fail if the sender
domain matches the HELO string. You can sometimes achieve similar
effects using the exists: mechanism, but in a lot of situations it's a
lot more cumbersome.
This is why we need a ESMTP proposal system. :-)
In general, because of the 25+ years of high helo damage already done in the
industry, it is a high overhead consideration.
At the very least, protect your own local domains first before deciding if
the overhead is justified for remote domain considerations. So for our
implementation, before SPF is activated, we have local domain/IP addressing
association rules, for example:
Reject if .santronics.com in .%CDN% and %CIP% != 208.247.131.9
Reject if .winserver.com in .%CDN% and %CIP% != 208.247.131.9
Which basically says that if HELO claims to be one our domains, then the
connecting IP better be from our known machine.
Its a lightweight LMAP (SPF) DOMAIN::IP check.
We explored this in a open-ended manner and the DNS and session time
overhead was too great.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com