It's not that hard to do but customers many be unwilling or unable to do it. If
it was me, I'd do all AV\AS on the same boundary machine but some customers
choose not to for a whole host of reasons.
I agree, it's not SPF and it does lose many advantages but again we have real
world customers in this very position asking for a solution.
Simon
---- Message from mailto:<johnp(_at_)idimo(_dot_)com johnp
<johnp(_at_)idimo(_dot_)com> at 23-Sep-2005 15:28:06 ------
Simon Tyler wrote:
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.
Surely it's not so difficult to add a mail account to a server to deal with the
mail
before it is forwarded to the AV?
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.
Well - that *really* isn't SPF. You are doing something else entirely and
losing the huge
advantage of rejecting before DATA. If you pitch your sales chat to the
customer
correctly, he will see the big advantage - the AV server will almost be
redundant if you
reject on fail and bad HELO, and then do some standard AV/UCE checking prioir
to
forwarding. Greylisting would probably kill off the rest of the rubbish.
Slainte,
JohnP.
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