For any educational institutions on this list - what has been the impact on
your mail services once your ISP started blocking port 25 - what if any was
the backlash - and how difficult was it to provide alternatives ...587,465
etc ...
best regards,
Our ISPs don't block anything, to my knowledge; but when our users'
ISPs began blocking port 25 (especially SBC DSL) we had already been
encouraging users to configure their clients to use 587.
matto
Paul,
For any educational institutions on this list - what has been the impact on
your mail services once your ISP started blocking port 25 - what if any was
the backlash - and how difficult was it to provide alternatives ...587,465
etc ...
Our ISPs don't filter our traffic. If they consistently did, they probably
wouldn't be our ISPs for long.
OTOH, the question that you didn't ask was if educational institutions
themselves are blocking port 25 from their users 
In our case, yes we are. We only allow SMTP connections from our dorm
subnets to the campus mail servers. Personally, I thought there
was going to be a huge backlash from our community when we put this in about
a year ago. Of the 12,000 students that this affected, I believe two have
inquired about it but didn't really have an issue with it.
Eric
The fact that most people did not complain is not likely due to the fact that they were not annoyed by the change, but rather it's easier to simply get around it than it is to bother complaining to network admins.
For example, about 2 months ago, comcast decided to block outgoing port 25 from my entire neighborhood. I called comcast, and while sitting on hold I had the idea to setup a ssh tunnel to a machine at work and viola problem solved before anyone from comcast even answered the phone.
Adam
Doesn't seem to be stemming the tide of emails from Comcast though:
<http://www.senderbase.org/?searchBy=organization&searchString=Comcast%20Cable>
-Hank
Doesn't seem to be stemming the tide of emails from Comcast though:
<http://www.senderbase.org/?searchBy=organization&searchString=Comcast%20Cable>
I'm not arguing about Comcast still spewing - they obviously still have issues
in that arena... *However*...
I'd take those numbers with at least a grain of salt, given that they're
showing my laptop as having an average "magnitude" of 4.6 (3.1 for today), and
our Listserv server an average magnitude of 4.8 (4.6 for today), saying that
long-run my laptop is generating almost as much mail as our Listserv box.
And that's not including the e-mail I post while my laptop is at other addresses.
I'll overlook the fact that my laptop has sent a whole whopping 16 pieces of
mail since midnight, and our Listserv has sent at *least* 40,000. Why the
discrepancy? Because when I post to a list like NANOG or a SecurityFocus list
or Linux-Kernel, it gets counted multiple times, once for each recipient
sampled by SenderBase....
And for extra fun, it appears that it counts *every* machine in the Received:
headers, as trapdoor.merit.edu scores a 5.3, segue.merit.edu a 4.3, and
testbed9.merit.edu a 4.0. Meanwhile, mail.merit.edu gets a 0.0, because it's not
showing up in the Received: lines for NANOG postings, most likely...
The fact that I can from a laptop with a little posting to a few large lists
rank higher than all but 53 of AOL's 2,553 listed sources should indicate that
perhaps those numbers aren't quite as useful as they appear.
Comcast.net has 31,923 addresses listed at the moment.
Do they have 30,000 zombies, or 30,000 customers that post to popular mailing
lists? Quite possibly at least partly the latter, as 24.22.118.199 ranks a 3.0
and isn't (as far as I know) a spam zombie, but a frequent poster to the
linux-kernel list. Meanwhile, of those 31,923, only 1,969 have a monthly
magnitude of 4.7 or more, the 4.8 cutoff is at 1,567, and the last 4.9 is at
1,012. And that 4.9 is (roughly) twice as much as I generate...
OK.. Think about that - of the 30,000+ listed, only 1,000 or so have measured
e-mail volumes significantly higher than one guy who posts a lot. Obviously,
either my laptop is infested with a spam-spewing AI zombie (which *has* been
alledged before), or the SenderBase numbers don't tell the whole story....
Another indication: from the message I'm replying to:
Received: from efes.iucc.ac.il (efes.iucc.ac.il [128.139.202.17])
by testbed9.merit.edu (Postfix) with ESMTP id 41125186B for <nanog@merit.edu>;
http://www.senderbase.org/search?searchString=128.139.202.17
Hmm.. the IP ranks a 2.5 for the last 30 days, but:
"No address list shown since no email was detected from iucc.ac.il."
http://www.senderbase.org/search?searchString=mail.iucc.ac.il
gets a "last 30 days" of 0.0.
Ooooh Kaaaay.. maybe we need more than just a pinch of salt here... 
Do all of Comcast's markets block port 25? Is there a correlation between
spam volume and the ones that do (or don't)?
In any event the malware is already ahead of port 25 blocking and is
leveraging ISP smarthosting. SMTP-Auth is the pill to ease this pain/
- Dan
Doesn't seem to be stemming the tide of emails from Comcast though:
<http://www.senderbase.org/?searchBy=organization&searchString=Comcast%20Cable>
Hmm, the onses who block everything and cut wires off send 0 spam. So what?
Do all of Comcast's markets block port 25? Is there a correlation between
spam volume and the ones that do (or don't)?In any event the malware is already ahead of port 25 blocking and is
leveraging ISP smarthosting. SMTP-Auth is the pill to ease this pain/
Really smtp-auth will solve it? or do most windows mua's cache your password?
They sure do cache the password.
But with smtp auth, the infected user is stamped in the email headers,
and all over my MTA logs, when a bot that hijacks his PC starts
spamming.
I can easily remove auth privileges for his account, and/or limit his
access to a walled garden till such time as he cleans up - without
taking the trouble to match timestamps of the spam + dig into radius
logs
Easier to identify, and easier to lock down, than unauthenticated access
--srs
Suresh Ramasubramanian wrote:
Not yet.
Of course, the same ISPs that will use the ID in the email headers are,
by and large, the same ones that already know how to match the IP in the
headers to their radius/tacacs/etc logs....
With a great deal less effort.
When you are trying to speed up processing of this sort, the less
effort wasted and less time taken nailing down one trojaned box the
better