On Sun, Sep 23, 2007 at 08:31:04PM -0400, Michael Scheidell wrote:
> One thing I would like to see (and this is a different subject:
> Marc: take note: Id like to NOT BOUNCE an email back to the victim of
> backscatter if they bothered to publish SPF or SENDER ID records that
> don't match the incoming.
>
> (and, yes, this would NOT work behind a proxy)
As I said, it *could* if the proxy in question at least puts in a
proper received header, and you can fish the info out of there. (If it
doesn't, I believe it's in serious violation of RFC 821/2821 and
822/2822; a mailserver MUST insert a Received header for itself.)
> I would like the proxy to at LEAST have a copy of the valid userlist,
> NOT muck with the headers.
Do I understand from this that 1) it's store-and-forward, not
transparently proxying, and 2) it doesn't currently validate the
recipients before accepting the mail? If so, that's a pretty strong
argument for either replacing or fixing it. Validating recipients at
the edge has been BCP for email for many years now.
Once the mail is accepted into the network, I think the onus is on
you collectively to either deliver or drop it, not bounce - not in the
current email regime. Not only does bouncing cause misery to others
whose addresses have been forged, not only does it make your company a
backscatter spam source - which could get you on DNSBLs - it also means
that you're doubtless wasting resources on having to accept and then
generate bounces for an absurd amount of mail for users who don't exist
except in the minds of some spambot.
If whoever's responsible for the proxy is not able to implement
normal recipient validation, I think this makes a good case that they
aren't able to keep it running adequately.
I realize I'm preaching to the choir, but perhaps this offers some
ammunition you can use to make your case.
> MAYBE do its load balancing via bridging rather than store forward.
If you can instead reengineer it to *shed* some of the existing load,
by introducing more up-to-date antispam measures, that might be better
than just balancing the load.
> That might fix a lot. But then again, it would be easier to replace the
> proxy than fix it.
It is starting to sound like it. But if you can do neither, I think
you're better off trying to never bounce any spam - configure the MTA
under your control to discard all undeliverable messages.
If company policy forbids that and says you *must* bounce mail to
undeliverable addresses, perhaps you can at least get it agreed to
bounce only *after* running the incoming stream through a spam/virus
filter set to discard, so that you would generate NDNs only for mail
which does not appear to be spam or a virus. This is the opposite of
what would normally be considered the desirable sequence, but if the
proxy is accepting the mail in the first place, and that's out of your
hands, you can at least reduce the volume of spurious bounces.
All IMHO, naturally
-- Clifton
--
Clifton Royston -- [EMAIL PROTECTED] / [EMAIL PROTECTED]
President - I and I Computing * http://www.iandicomputing.com/
Custom programming, network design, systems and network consulting services
