On Mon, 21 Jun 2004 23:00:35 +0200, Rolf E. Sonneveld wrote:
<snip>
I see another major obstacle (with the Caller-ID PRA
mechanism) in the many firewall and anti-virus SMTP implementations.
Firewall vendors tend to be extremely conservative in adding
new (E)SMTP
commands/keywords. Anti-virus SMTP vendors most of the time are doing a
great job at scanning messages for viruses, but they're usually doing a
very poor job in the proper handling of the SMTP protocol (and SMTP
extensions). And a significant number of companies do use these
firewall
and anti-virus SMTP implementations between their internal network and
the Internet.
I don't expect both groups of vendors will change their
software soon to
support something like Caller-ID PRA.
I have to agree that these vendors do not produce the greatest
SMTP servers (or clients), in fact it's so good, that I have
had to use extra sendmail daemons to do all the "security stuff"
before passing it onto the AV daemon. Basically it's the refuse
before accept issue, we do not want to bounce, which when using
an AV daemon as the primary listner, tends to happen rather a
lot.
These same AV vendors are not going to be carrying out the
SPF/PRA checks at the gateway either, so if they do not support
the ESMTP extenstions for PRA, it makes no difference.
If you want SPF/PRA checking at the gateway, you need server
software capable of doing these checks, and it is not likely to
be provided by the AV vendor.
The place it could be an issue is when the AV software is
delivering directly by MX, since it will not be able to provide
the ESMTP extensions required. Though if an organisation
understood the need of SPF/PRA inblound, hopefully they would
get the outbound sorted.
I don't therefore see the ability of AV software vendors to add
ESMTP enhancements to their products having any impact on
SPF/PRA, but worth noting that the outbound MX implentation
needs to be considered.
Regards
Karl Prince
______________________________________________________________
Email via Mailtraq4Free from Enstar (www.mailtraqdirect.co.uk)