Why would it obviously match? Take your email headers I just received. If I had
"apex.listbox.com" as my gateway machine. I could search down, find the header:
Received: from miranda.server-plant.co.uk (miranda.server-plant.co.uk
[193.110.88.60])
by apex.listbox.com (Postfix) with ESMTP id 144B055773
for <spf-discuss(_at_)v2(_dot_)listbox(_dot_)com>; Fri, 23 Sep 2005 09:41:26
-0400 (EDT)
extract your IP address - 193.11.88.60
and then use it to check the SPF record. We wouldn't be able to HELO checks.
And I guess I am assuming that the forwarding servers preserve your MAIL FROM
clause - not unreasonable as I have assumed they are not SPF aware. And I find
you pass.
Actually your email is not a good example (or perhaps it is) as
apex.listbox.com has 2 Received lines and I want the second one. So the method
of identifying which Received line you want is more complicated (and hence
error prone) than I first thought.
It *is* alot of checks and I don;t really like it but I am tryting to find a
solution to a problem that doesn't just involving saying to the customer
"tough, move your AV gateway or move your SPF check".
Simon
---- Message from mailto:<johnp(_at_)idimo(_dot_)com johnp
<johnp(_at_)idimo(_dot_)com> at 23-Sep-2005 15:40:59 ------
Simon Tyler wrote:
We haven't added anything yet. The idea would be for teh customer to somehow
enter the
name of the boundary server, say "avgateway.somewhere.com". We would then
step back
through the headers until we found it and extract the IP address from that
header.
And do what with it? It will obviously match, so that is going to tell you
nothing.
It is open to forgery but one assumes that the user trusts their AV gateway
to add the
correct header and that the mail is sent straight from the AV gateway to the
user
through only trusted machines.
That's a heck of a lot of assumptions for an e-mail authenticity check :-/
SLainte,
JohnP
Simon
---- Message from mailto:<dan(_dot_)field(_at_)accessemedia(_dot_)com "Dan
Field"
<dan(_dot_)field(_at_)accessemedia(_dot_)com> at 23-Sep-2005 14:21:59 ------
What process will you use for stepping through the received headers?
Doesn't this leave you open to forged headers?
Thanks.
Dan
-----Original Message----- From: Simon Tyler
[mailto:simont(_at_)gordano(_dot_)com] Sent: 23
September 2005 14:18 To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com Subject:
Re: [spf-discuss] Re: SPF
and gateways
Actually I am rather hoping they do not know their trade as outsourced AV is
bad for
business as we sell a competing (not outsourced) AV product :-) Alas it is a
fact of
life that some people do outsource, so I need a solution.
So far I have only the MX record option which has the issue that the customer
needs an
additional mail server - not really an option for most people especially if
they need
to buy one.
The Received headers option is still my favourite - I know it means the AV
gateway will
have accepted the whole message and you lose the ability to reject at the
MAIL FROM
stage but that is life - if the customer really needs to reject at the MAIL
FROM or
wants rejects to be correctly handled then they have the option of using
either the MX
record solution or moving either the SPF check to the AV gateway or ditching
the AV
gateway altogether and moving AV on their SPF mail server.
Simon
---- Message from mailto:<nobody(_at_)xyzzy(_dot_)claranet(_dot_)de Frank
Ellermann
<nobody(_at_)xyzzy(_dot_)claranet(_dot_)de> at 23-Sep-2005 13:52:39 ------
Mark wrote:
I believe it to be good practice to just drop infected mail altogether, as I
hold the
belief that a virus, or other malware, should never be reintroduced. or
caused to be
reintroduced, into the mail stream again.
Yes. But in the early days of ClamAV the results were not always correct,
and if it's
(ab)used to catch phishing there could be dropped FPs. OTOH Simon's case is a
professional AV-server - he can hope that they know their trade and get it
right. Bye,
Frank
------- Sender Policy Framework: http://spf.pobox.com/ 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
---------------------------------------------------------------------- Sender
Policy
Framework: http://spf.pobox.com/ 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
---------------------------------------------------------------------- Sender
Policy
Framework: http://spf.pobox.com/ 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
------- Sender Policy Framework: http://spf.pobox.com/ 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
-------
Sender Policy Framework: http://spf.pobox.com/
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
-------
Sender Policy Framework: http://spf.pobox.com/
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