Take a look at the following post from the SPF list.
One thing it shows is that this particular user has a problem that is
due to his local mail configuration.
Rather than telling him to fix it (he won't) I think we need to accept
that any set of rules for processing records are going to be affected
by the local mail configuration.
So rather than having the 'debate' proposed in the charter as to which
aspects of a mail message are the 'right' ones to use I think we should
try to write a spec that does not need the debate.
The quickest way to write the spec is to specify the least amount that
is required in order to achieve interoperability with a sender and a
receiver.
If the receiver is a standard one and the mail has not been transfered
through a forwarder it does not matter which of the attributes are
used they should all work as well.
If you work at the gateway then you can use the SMTP FROM address and
the results will work.
If you are writing a client side filter you are going to have to be
clever and work out how to sense what the local mail config happens
to be and adapt.
The point is that we do not need to write normative text for the receiver
end, and even if we do write normative text it can and should be ignored.
The only point where the text needs to be normative is at the generator
end. And that is where the sender gets told 'before you deploy SPF records
make sure your mail server is in compliance with these particular
RFC 2821 etc requirements.' when necessary.
Writing the spec in a declarative fashion becomes quite easy. You simply
tell the sender to list out the set of all outgoing mail services at
the edge of their network that you wish external receivers to accept
mail from. You then provide simple ways to encode that set:
1) A list of the IP addresses themselves
2) By reference to other configuration data (e.g. mx records)
3) By reference to a look up service
Where we can argue over which of these are necessary/desirable/etc.
The point is that it is pretty easy to describe the semantics of the
entries unambiguously. That is the part of the spec that has to be
normative. That is the part of the spec that has to be reviewed
extensively.
One idea here would be we divide the spec into two documents, the
first a purely normative spec which describes the data the sender
wants to put into the DNS. The second would be an informational guide
that describes ways the information can be used.
Phill
-----Original Message-----
From: owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
[mailto:owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com]On Behalf Of Alain
Knaff
Sent: Tuesday, March 16, 2004 8:33 AM
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Cc: Greg Cirino - Cirelle Enterprises
Subject: Re: [spf-discuss] Everyone Having an SPF Record Fails From This
List
begin Tuesday 16 March 2004 14:03, Greg Cirino - Cirelle Enterprises quote:
I have a qmail system running maildrop which
calls spfquery with the appropriate headers and
It appears everyone that has an spf record in their
dns fails to this list, all others return none.
(i add headers to incoming mail to identify this)
Is this the expected behavior?
No, this is not expected...
according to:
http://spf.pobox.com/newheader.html
When an SPF query returns "fail", the MTA should reject the connection.
There would be a lot of mail going to the bit bucket,
or whatever, if I did that.
Usually, mailing lists are supposed to put the listmasters address in
the enveloppe From (in this case
owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com),
and the spf list does indeed set this correctly (or else many other
people, such as myself, would reject the list as well...).
Maybe what is happening is that some program local to you is stripping
the envelope From, and then reinitializing it from the header From?
Regards,
Alain
-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Latest draft at http://spf.pobox.com/spf-draft-200403.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=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com