I work in development - I don't get to say which customers are worth keeping. I
guess sales would say all of them :-)
Customers want to use other AV gateways for all sorts of reasons - perhaps it
is corporate policy to use XYZ AV software so they choose a gateway which has
it. Perhaps they have an ISP who does it for free. Perhaps it's simply cheaper
(but obviously not as good :-) ). Perhaps they have a layered AV\AS solution
where the email goes through 2 or 3 AV\AS servers. Who knows. They do it.
It may well be that the technical solution is just too
messy\awkward\un-reliable and we will choose not to do it. But I have to look -
I was hoping someone would have thought it through and come up with a solution.
Alas not (other than move the SPF to the boundary).
Simon
PS Hope you liked the website. It's email software not services (sort of).
---- Message from mailto:<johnp(_at_)idimo(_dot_)com johnp
<johnp(_at_)idimo(_dot_)com> at 23-Sep-2005 15:49:47 ------
Simon Tyler wrote:
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.
OK - maybe I'm not properly understanding the relationship between you, your
servers, your
customer, and his servers. Since you are a provider of e-mail services (I had
a look at
your website) I am not sure how your customer has ended up wanting to use a
third-party's
AV server. Is he really worth the hassle? You run the risk of fouling your own
service
with potential false positives, lost mail, etc. I'd say it isn't worth it.
It's all very
well to bend over backwards for customers, but they have to live in the real
world too -
and having a messy e-mail setup is just plain bad.
Slainte,
JohnP
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
-------
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