Hallam-Baker, Phillip wrote:
The client queries will almost certainly break because most
companies will not allow inetd queries.
Then they should not configure their domains with %{u} !!!
They will not be able to read email from a domain that uses the macro.
The effect that you are trying to achieve here is to only allow one
process
to send mail from a machine. That can be achieved far more easily by
O/S
level configuration. Simply block permission to connect to port 25
outgoing
to any process other than the mail server process.
Protocol should not be a substitute for local machine config.
Normally, I would agree with this 100%. This sounds like a perfect case
for local firewall policy. However, I can see a scenario where you may
want to define a remote host as being allowed to send mail for your
domain, but you only want your user account on that host to be the one
allowed to do it. In that case, you do not control the firewall policy
on that host, you simply have a user account, and you only control the
SPF policy for your domain. If the admin of that host allows the users
to send mail directly from that host, you may want to make use of that
and declare it as legal in your SPF policy.
I see the points being made on both sides of this issue, and I see the
usefulness and limitations of the macro, yet I'm not really sure where I
stand on it. Maybe I'll lurk a while longer and see if anyone makes any
more really good points.
---
Dustin D. Trammell
Vulnerability Remediation Alchemist
Citadel Security Software, Inc.
-------
Sender Permitted From: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Latest draft at http://spf.pobox.com/draft-mengwong-spf-02.9.5.txt
Wiki: http://spfwiki.infinitepenguins.net/pmwiki.php/SenderPermittedFrom/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname(_at_)½§Åv¼ð¦¾Øß´ë ù1Ií-»Fqx(_dot_)com