[Mimedefang] [OT] Re: Clearing history for 63.216.184.10 - Useful Borderware Manager Discussion

[Kevin A. McGrail]

Chris:

Thanks for your reply.  I'll try and respond in detail and cc the MD List 
for more comments because they are the best group of people I've met for 
sounding out a myriad of issues related to email delivery in this day and 
age.

My first answer is that besides a manual configuration, MXtreme could do an 
MX lookup on the domain you are receiving and see if the host is a relay 
listed as a standard MX record if it's a local-host-name or allowed relay. 
This will allow you to automatically exclude "trusted" relays from your 
reputation system and could be cached based on the standard TTL settings for 
the domain.

At that point, the choice to utilize Backup MX's becomes a choice of the 
customer elected by DNS rather than something a person who may not know what 
they are doing has to set.

My second answer is that even with the above automation or manual 
identification of customers, I don't see how it would help.

Company X is down.  We queue mail for them.  When they come back up, 80% of 
the mail is then flagged for invalid recipient and our machine generates a 
proper RFC-driven NDR which goes back then to a potentially forged address 
of someone who is not related to us and happens to run your product.   It's 
not ideal and when things are working correctly, we do limit queuing to the 
extent possible.  However, in the end, backup MX's and NDRs are designed for 
when things are not ideal and something went wrong.  We cannot just ignore 
this and ignore NDRs.

My third answer on this is that just because NDRs are create by spammer I do 
not believe means people are reading them.  I would argue the vast majority 
are wasted emails that are caused by old mailing lists, joe-jobs and 
dictionary attacks.  I'd like to hear more if you believe they are actually 
using NDRs as a delivery method because it just doesn't make sense.  Most 
users don't know what one is, let alone know how to decipher it or get to 
the original email attached.  Therefore, other than annoying by volume, are 
NDRs an issue of actually being effective spam?  Your FAQ definitely leads 
me to believe this.

My fourth answer would be that IF you mark NDR's as SPAM then you implement 
a policy similar to AOL.

For example, we forward a LOT of email to AOL.  However, we do not 
fundamentally agree with any blocks for SPAM scores.  SPAM is in the eye of 
the beholder and FPs are a reality.

However, AOL DOES have a whitelist system and on top of that, they honor the 
X-Spam-Flag: Yes.  They, in fact, use this flag to automatically place the 
email into the users junk folder.

This doesn't cover my issue with the fact that AOL believes it's users too 
much as almost 100% of our "spam" feedback is legitimate mailing lists.  And 
I don't even mean legitimate marking mailing lists.  We are talking things 
like volunteer fire departments and internal mailing lists for Jerry's Subs 
and Pizza franchise members, Autism member organization lists, etc.  These 
people sign up and then use the "this is spam" as a "don't put this in my 
inbox" filter.  Argh!

But, I would argue you need a similar policy where if you are to hold NDRs 
against a company, you at least allow them to place and subsequently honor 
the X-Spam-Flag: Yes.  In short, "Yes, it's potential SPAM but the company 
is still going to deliver an NDR anyway" to exclude from the reputation 
system.

The problem with the end-result however is that spammers can simply put 
X-Spam-Flag: Yes into their headers and that's it.  For AOL, that's fine 
because it is filtered as junk mail automatically.  Therefore, I believe 
that if you made a change to MXTreme to utilize existing POSITIVE spam flag 
headers but ignore NEGATIVE headers (i.e. ignore X-Spam-Flag: No), and make 
it a user switchable option, you will A) save processor cycles if another 
box says it's SPAM, and B) be able to exclude it from the reputation 
measure.   Then those who run spam tests on NDRs can continue to do so and 
everyone is happy.  Of course, we'll have to figure out HOW to enable SPAM 
testing on NDRs but that is another issue.

Regards,
KAM

----- Original Message ----- 
From: "Chris Gabe" <chris at borderware.com>


> Yes no doubt.  We saw your post to mimedefang too.  We understand the pain 
> of NDR, oh do we ever.  The thing is, if over half the email is NDR spam, 
> well, trying to get people to stop it is arguably a whitehat initiative 
> too.  Over half the people that contact us don't know what NDR is, and 
> many manage to stop most of it.  If that's our first line defence, it's 
> not a bad one.
> The next question is though, you mentioned you are the backup mx for a 
> bunch of organizations.  There are facilities to deal with this in our 
> system.  Our customers can identify your ip as a relay and not report your 
> traffic.  If there's only a couple, we'd do that.  If there's many many 
> customers reporting you, we won't bother, we'd need to consider a 
> whitelist.  To date we only have about 10 such ip's (this is after a year 
> of this service running in thousands of customers).  Let us know your 
> thoughts.  There's more detailed information below but it sounds like you 
> know the scoop on things.