On 15-09-10 05:13 AM, Rich Kulawiec wrote:
Spam (and all other forms of abuse) is/are best stopped as close to the
source as possible: every hop away from there makes the problem harder
and pushes the error rate up. Thus the ideal place is*at* the source.
This doesn't require SPF or SRS or DKIM or any of these other bits of
technology. It requires competent, diligent, hard-working professionals
who actually give a damn about making sure that their operation isn't
an operational menace to the entire rest of the Internet.
While you are absolutely right that network operators and email server
operators should be the place that the majority of the work is done (at
the source), (egress filtering, blocking DUL traffic to Port 25 et al),
and simple monitoring and rate limiting.
(Today's pet peeve, I am talking to all those VPS houses that let people
sign up online, possibly with a stolen credit card or bitcoin, and have
access to a big PIPE, get a block of IP(s) and then 'crush' the internet
with spam, while the hosting operator acts 'surprised'.. you can tell
what is happening on your network, don't put the onus on the rest of the
internet to deal with it)
But in the end, the final decision of what is spam and what isn't lies
with the recipient.. "One man's spam, is another man's reading
material" What bother me most is that many of 'these other bits' of
technology, are work around's for simpler technologies.
ESP's have to stop sending 'rewritten' forwarded email, which simply
obfuscate the real sender.. bou...@esp.com doesn't allow the end user to
make decisions.. not matter what the technical excuse..
* We want to receive bounces for our customers.. so we can remove bad
addresses..
- Really? First, why do you have so many bad addresses?
- For bounces? Haven't we already classed that as 'backscatter?
- End user should be able to reject based on sender, don't hide that.
(oh, if we send them all the same, hehehe, no-one can blacklist)
but you also prevented the reciever from 'whitelisting' easily
Okay, looks like I am going to start the day with a 'rant'..
<bounce-mc.us4_17755707.723909-user=test....@mail24.suw11.mcdlv.net>
<awnmwg9zxqvcotrqzko54na==_1108436388887_enwnwgvgeeodknsuupk5pg==@in.constantcontact.com>
<bou...@serv09-bl.com.br>
<bounce+e58cb7.4739-user=test....@birdeye.info>
<bounce-user=test....@propertyonesg.com>
<bounce-2489-20611-user=test....@v2.b2bmail.in>
<bounce_246010.4291645.2722856.3446.m.be6ca...@bounce.citrusemail.com>
<bou...@eromailsystem.com>
<bounces+529963.80910796.876...@icpbounce.com>
Some ESP's at least some identity related to the domain, which is better
than nothing..
<bounces+1170988-7f25-user=test....@email.nationbuilder.com>
But of course end users are used to putting '@nationbuilder.com' in the
blacklist/whitelist, or even maybe '@constantcontact.com' but what
ordinary citizen would think.. '@in.constantcontact.com'?
What ever happened to clearly identifying the sender?
Should an email server have to process thousands of messages, just so
they can parse the headers and see if a 'forgable' From: address is the
one they want?
(Yes, there are specific cases of mailing lists that need strange
sending addresses, but at least they have the domain portion right)
Return-Path: <mailop-boun...@mailop.org>
If we clearly presented the senders's half of these 'other technologies'
would not be needed.
clean rDNS/PTR record, clean Return-Path, proper rWhois/SWIP would make
things a lot simpler..
<end rant>
--
"Catch the Magic of Linux..."
------------------------------------------------------------------------
Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
------------------------------------------------------------------------
A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.
------------------------------------------------------------------------
604-682-0300 Beautiful British Columbia, Canada
This email and any electronic data contained are confidential and intended
solely for the use of the individual or entity to which they are addressed.
Please note that any views or opinions presented in this email are solely
those of the author and are not intended to represent those of the company.
_______________________________________________
mailop mailing list
mailop@mailop.org
http://chilli.nosignal.org/mailman/listinfo/mailop