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.
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.
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