Discussion:
FTC asks ISPs to crack down on zombie PCs
(too old to reply)
Matthew.van.Eerde at hbinc.com ()
2005-05-24 22:18:01 UTC
Permalink
http://www.ftc.gov/opa/2005/05/zombies.htm

"
... will send letters to more than 3,000 ISPs around the world, urging them to employ protective measures to prevent their customers' computers from being hijacked by spammers. The measures include:

* blocking a common Internet port used for e-mail when possible;
* applying rate-limiting controls for e-mail relays;
* identifying computers that are sending atypical amounts of e-mail and take steps to determine if the computer is acting as a spam zombie. When necessary, quarantine the affected computer until the source of the problem is removed;
* providing plain-language information for customers on how to keep their home computers secure; and
* providing or pointing their customers to easy-to-use tools to remove zombie code if their computers become infected.
"

About time, too...
--
Matthew.van.Eerde (at) hbinc.com 805.964.4554 x902
Hispanic Business Inc./HireDiversity.com Software Engineer
perl -e"map{y/a-z/l-za-k/;print}shift" "Jjhi pcdiwtg Ptga wprztg,"
Ben Kamen
2005-05-24 22:23:43 UTC
Permalink
Post by Matthew.van.Eerde at hbinc.com ()
http://www.ftc.gov/opa/2005/05/zombies.htm
"
* blocking a common Internet port used for e-mail when possible;
* applying rate-limiting controls for e-mail relays;
* identifying computers that are sending atypical amounts of e-mail and take steps to determine if the computer is acting as a spam zombie. When necessary, quarantine the affected computer until the source of the problem is removed;
* providing plain-language information for customers on how to keep their home computers secure; and
* providing or pointing their customers to easy-to-use tools to remove zombie code if their computers become infected.
"
About time, too...
From the looks of SpamHaus.org, UUnet/MCI is one of the biggest parts of the
problem... the FTC should be sending them more of "look here guys... if you
don't stop the spammers on your networks, we're gonna have to come kick your
collective butt-ski's" kinda letter.

-Ben
Ben Kamen
2005-05-24 22:26:19 UTC
Permalink
Post by Matthew.van.Eerde at hbinc.com ()
About time, too...
As a sidenote: They should also be writing a letter to Mr. Bill (Oooooo Noooooo)
asking his darn company to stop writing so many darn bugs into the OS.

We just all want to be free... IE/Outlook free that is. ;)


-Ben

p.s. I think we need a new bumper sticker... "Geeks don't let friends run
IE/Outlook".
Curtis
2005-05-24 22:58:27 UTC
Permalink
Matthew,

Thank you for sharing this. It is about time more
people get involved in this growing and out of control
menace to Internet society.

Curtis
Post by Matthew.van.Eerde at hbinc.com ()
http://www.ftc.gov/opa/2005/05/zombies.htm
"
... will send letters to more than 3,000 ISPs around
the world, urging them to employ protective measures
to prevent their customers' computers from being
* blocking a common Internet port used for
e-mail when possible;
* applying rate-limiting controls for e-mail
relays;
* identifying computers that are sending
atypical amounts of e-mail and take steps to
determine if the computer is acting as a spam
zombie. When necessary, quarantine the affected
computer until the source of the problem is removed;
* providing plain-language information for
customers on how to keep their home computers
secure; and
* providing or pointing their customers to
easy-to-use tools to remove zombie code if their
computers become infected.
"
About time, too...
--
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
James Ebright
2005-05-25 14:03:42 UTC
Permalink
Post by Matthew.van.Eerde at hbinc.com ()
* blocking a common Internet port used for e-mail when possible;
* applying rate-limiting controls for e-mail relays;
* identifying computers that are sending atypical amounts of e-
mail and take steps to determine if the computer is acting as a spam
zombie. When necessary, quarantine the affected computer until the
source of the problem is removed;
* providing plain-language information for customers on how to keep
their home computers secure; and
* providing or pointing their customers to easy-to-use tools to remove
zombie code if their computers become infected. "
Well it is about time, but....

Any ISP worth a damned already does all of the above and more, the issue is
not so much with ISPs but with telcos that have creeped into the ISP market
for residential customers. (i.e. the MCIs and Sprints [and others]). Focusing
there will deliver the most bang for the FTCs buck so to speak as competition
has killed off most of the ISPs that were clueless.

Also note, the FTC has changed the text of the letter a bit, the relevant
points now read:

* block port 25 except for the outbound SMTP requirements of
authenticated users of mail servers designed for client traffic. Explore
implementing Authenticated SMTP on port 587 for clients who must operate
outgoing mail servers.
* apply rate-limiting controls for email relays.
* identify computers that are sending atypical amounts of email, and take
steps to determine if the computer is acting as a spam zombie. When necessary,
quarantine the affected computer until the source of the problem is removed.
* give your customers plain-language advice on how to prevent their
computers from being infected by worms, trojans, or other malware that turn
PCs into spam zombies, and provide the appropriate tools and assistance.
* provide, or point your customers to, easy-to-use tools to remove zombie
code if their computers have been infected, and provide the appropriate
assistance.

But really the first item should be:

* block outbound port 25 except for designated MTAs. Define a SPF record for
said MTAs. Implement SMTP Auth.

(sidenote: port 587 is not sufficient for TLS auth, also need 483 thanks to
good ole M$ and outlook)

The other repurcusion, probably an unavoidable one in the long term anyway, is
zombies will now be created that can hijack a users mailsettings and
credentials to then relay mail, which will improve the spam message structure
considerably as well since many MTAs correct things that ratware normally
foobars and as a result will remove many of the footprints things like SA look
for.

Just my $0.02,

Jim
--
EsisNet.com Webmail Client
Ian Mitchell
2005-05-25 14:51:26 UTC
Permalink
Date: Wed, 25 May 2005 09:03:31 -0400
Subject: Re: [Mimedefang] FTC asks ISPs to crack down on zombie PCs
Post by Matthew.van.Eerde at hbinc.com ()
* blocking a common Internet port used for e-mail when possible;
* providing plain-language information for customers on how to keep
their home computers secure; and
Personally, I'm highly opposed to blocking outbound port 25. There are
some of us who don't have the resources to run a domain on a business
class line. Second off, there are those of us who take security very
seriously and work hard to ensure our micro domains don't become zombies.
And third, one could use the argument that we should use hosting services.
But I did use a hosting service when I first got started. And when I
attempted to use Frontpage to modify my website one day, I realized that
none of the 14,000 websites hosted by the provider were password
protected. I can do better than that on my home PC.

So by cutting our port 25, we are now forced to limit which domains we can
send email too. I have to add special rules to those specific domains that
choose to deny my emails to forward through my ISP's MTA. The point of
running an MTA is so you don't have to do that.
* block outbound port 25 except for designated MTAs. Define a SPF record
for
said MTAs. Implement SMTP Auth.
Only if the email presents itself as being from that domain, if someone's
running a domain on an IP of that ISP, then that domain should have an SPF
record that SHOULD allow the emails to go through. I advertise a hard SPF
record for my domain, I allow email to only come from my IP. Unfortunately
due to the rules that I have to set up for certian ISP's that limit port
25, I have to allow my ISP to act as a relay in the SPF record as well.
Not my most ideal solution. But it's that kind of backwardness you get
when people start breaking things ;)
The other repurcusion, probably an unavoidable one in the long term
anyway, is
zombies will now be created that can hijack a users mailsettings and
credentials to then relay mail, which will improve the spam message
structure
considerably as well since many MTAs correct things that ratware normally
foobars and as a result will remove many of the footprints things like SA
look
for.
As long as the current model for SMTP exists, spam will exist.

I visited a security seminar just a few weeks ago and they demo'd a
product that would probably be pretty decent to look at for any ISP that's
looking to set up an automatic quarintine mechanism. It's called ForeScout
and the way it works is it monitors for very specific attack signatures
(NMAP scan) and once it detects it, it launches it's own man in the middle
attack. For the asset being protected, it sends RST packets to all out
bound connections associated with the attack. For assets doing the
attacking, it creates a honeynet and records all the traffic for forensic
analysis later on. Definately a pretty decent tool, and it can definately
assist in shutting down zombies.

I personally am opposed to any device that "attacks" but apparently
there's a non-existant false positive rate and the idea seems pretty
solid.
Ben Kamen
2005-05-25 15:47:36 UTC
Permalink
Post by Ian Mitchell
Personally, I'm highly opposed to blocking outbound port 25. There are
some of us who don't have the resources to run a domain on a business
class line. Second off, there are those of us who take security very
seriously and work hard to ensure our micro domains don't become zombies.
And third, one could use the argument that we should use hosting services.
But I did use a hosting service when I first got started. And when I
attempted to use Frontpage to modify my website one day, I realized that
none of the 14,000 websites hosted by the provider were password
protected. I can do better than that on my home PC.
I am opposed to blocking ANYTHING as well - but what can be done? The problem is
MS at this point. The FTC really needs to start making them accountable for the
crap they are putting out in the public domain. I'm not sure quite how to make a
legal standing out of this...but I'm definitely not one for going after
gun-makers when bad people use 'em to shoot good people.

On another note, I cancelled SBC because they started blocking protocol 50
packets for my VPN. And I was on a static IP package which isn't supposed to
have ANY filtering. We finally determined they changed something on their PPPoE
servers that fudged my configuration that had been working perfectly for 13
months. Their answer? Buy a new modem. (like it was now my problem when they
figured out the problem was at their end)

My point being: I'm seeing this disturbing trend that can best be described as:

We (the ISPs) can't manage/run/maintain our networks for our everyday customers.
So let's stick it to the folks who need more by offering "business class"
service which will help pay for the people who are smarter than monkeys we have
running the system now.

What "resources" do you need to run a domain on a business class line other than
maybe one "slow" (by today's standards) linux box? Or are you talking about the
screw'em factor the ISP's are engaging in now for "business class" service?
Post by Ian Mitchell
So by cutting our port 25, we are now forced to limit which domains we can
send email too. I have to add special rules to those specific domains that
choose to deny my emails to forward through my ISP's MTA. The point of
running an MTA is so you don't have to do that.
I'm one of those domains. I get hammered by Comcast, Verizon, SBC and others. I
hate the concept of blocking port 25 too! (I was recently in St. Louis using the
hotel's free wireless only that they block p:25 too. So I switched to 587 since
I'm using an MSA anyway... but still, what's the point of advertising "internet
access" when it really only means selected ports.)

I know one person who not only MTA's from behind an ISP with known spam
problems, but he's tried to use a DynDNS provider who can't keep their
secondaries in sync... what am I supposed to do with that??
Post by Ian Mitchell
Only if the email presents itself as being from that domain, if someone's
running a domain on an IP of that ISP, then that domain should have an SPF
record that SHOULD allow the emails to go through. I advertise a hard SPF
record for my domain, I allow email to only come from my IP. Unfortunately
due to the rules that I have to set up for certian ISP's that limit port
25, I have to allow my ISP to act as a relay in the SPF record as well.
Not my most ideal solution. But it's that kind of backwardness you get
when people start breaking things ;)
Ok - again. We're talking about monkeys working for companies that want to
charge an extra fee per month just to have a "custom" PTR record in DNS! Set
once, charge many.
Post by Ian Mitchell
As long as the current model for SMTP exists, spam will exist.
I visited a security seminar just a few weeks ago and they demo'd a
product that would probably be pretty decent to look at for any ISP that's
looking to set up an automatic quarintine mechanism. It's called ForeScout
and the way it works is it monitors for very specific attack signatures
(NMAP scan) and once it detects it, it launches it's own man in the middle
attack. For the asset being protected, it sends RST packets to all out
bound connections associated with the attack. For assets doing the
attacking, it creates a honeynet and records all the traffic for forensic
analysis later on. Definately a pretty decent tool, and it can definately
assist in shutting down zombies.
And just think - all thanks to MS (well, mostly anyway).




-Ben
Kenneth Porter
2005-05-25 18:11:52 UTC
Permalink
Post by Ben Kamen
We (the ISPs) can't manage/run/maintain our networks for our everyday
customers. So let's stick it to the folks who need more by offering
"business class" service which will help pay for the people who are
smarter than monkeys we have running the system now.
Agreed. I wouldn't be opposed to blocking port 25 if there were a way to
get it unblocked for the clueful, like a web page that takes someone
slightly more savvy than a monkey to navigate, and that you don't get free
help to fill in. (Maybe require the user to solve a sendmail rule puzzle!)
James Ebright
2005-05-25 18:35:19 UTC
Permalink
Post by Kenneth Porter
Agreed. I wouldn't be opposed to blocking port 25 if there were a
way to get it unblocked for the clueful,
We unblock port 25 for _static_ IP customers that request it, but we also swip
their netblocks to them so those potential complaints dont come back to us
anyway if that static customer did have a spam/virus/etc related issue :-)

But, coming from the ISP side of things.. I am sorry.. dynamic IP space should
have port 25 blocked, it is the only responsible thing to do and has been our
policy (you do read EULAs and TOSs before agreeing to them dont you?) for over
2 years now, with _zero_ complaints. We do provide Authentication for users on
both port 25 and 587 (port 587 users MUST authenticate) as well. 99.9% of our
dynamic IP customers use our own MTAs for sending their mail, this does not
affect recieving mail one iota. Those that do not use one of our MTAs use a
different port for outgoing (like 587) to their other mail server or use a VPN.

Jim
--
EsisNet.com Webmail Client
Kenneth Porter
2005-05-25 19:07:01 UTC
Permalink
--On Wednesday, May 25, 2005 1:35 PM -0400 James Ebright
Post by James Ebright
We unblock port 25 for _static_ IP customers that request it, but we also
swip their netblocks to them so those potential complaints dont come back
to us anyway if that static customer did have a spam/virus/etc related
issue :-)
What premium do you charge for that? (I wouldn't mind 5%, but 100% is way
too much.)

Unfortunately I'm located where I can only get cable as the telco CO is too
far away for DSL. (Otherwise I could get Speakeasy, which has always been
server-friendly and alternative-OS-friendly.)
James Ebright
2005-05-26 16:27:05 UTC
Permalink
Post by Kenneth Porter
What premium do you charge for that? (I wouldn't mind 5%, but 100%
is way too much.)
Our monthly recurring price actually does not change with regards to whether
or not you are a business or residential customer with regards to DSL pricing,
what does change is the terms of the contract, what packages are available,
what service levels you agree to, your payment plans and options, terms of
service, it is a seperate contract entirely than our residential one, business
customers can choose to add on extras that are not available to residential
and some packages just are not available to resedential customers, in other
words, some business get charged the same as the resedential customer with the
same service level, some have added on additional features for a bit more (for
instance, we do not sell (nor could we justify the allocation of to arin)
blocks of IP space to resedential customers).

In other words, you are not "penalized" price wise if you are a business
customer with our company. In fact, it opens up extra options and features to you.

Jim




--
EsisNet.com Webmail Client
ADNET Ghislain
2005-05-25 18:45:00 UTC
Permalink
Post by Kenneth Porter
Agreed. I wouldn't be opposed to blocking port 25 if there were a way
to get it unblocked for the clueful, like a web page that takes
someone slightly more savvy than a monkey to navigate, and that you
don't get free help to fill in. (Maybe require the user to solve a
sendmail rule puzzle!)
imho the cluefull people use a real server in a hosting center or use
professional contract with ISP that allow them to have such rules,
personnal adsl lines should not have such options. Little users should
use the ISP smtp server or any cheap hosting server that comme with it.
I do not see why you would use your own adsl or cable modem link to send
emails. Obviously if you can receive emails for your domain you can also
send them as it requires a domain name and therefor a pop/smtp server ?

Can you broaden my vision of thing and give some exemples where the
hoster's smtp server and the ISP smtp server is not enough so you would
want to use your own internal smtp server to send emails from a
dsl/cable line ? As far as my short sight see the only reason i see is
hidding behing unstable ip and fairly untrackable source (yes this is
fairly limited but meant to make people react and enlighten me rather
than drop this mail to the trashcan :) ?

Any way if the use are limited i think changing the habbit of a
minority toi protect the internet as a whole is a good trade off :)

best regards,
Ghislain.
--
Gary Schrock
2005-05-25 19:32:08 UTC
Permalink
Post by ADNET Ghislain
Can you broaden my vision of thing and give some exemples where the
hoster's smtp server and the ISP smtp server is not enough so you would
want to use your own internal smtp server to send emails from a
dsl/cable line ? As far as my short sight see the only reason i see is
hidding behing unstable ip and fairly untrackable source (yes this is
fairly limited but meant to make people react and enlighten me rather
than drop this mail to the trashcan :) ?
It's not so much that I'd want to use an internal server on my adsl
network, but that I should NEVER be forced to use the isp's mail
server. Blocking outgoing port 25 prevents me from using my own legit
business server at work. Why would I want to send my email through a large
isp server where it will take who knows how long to make it through the
system, when I can send it through my controlled work server, which has
very little load and I know the email will get through right away? (Ok,
maybe if they don't block 587 also, but let's face it, it's just a matter
of time before isp's start doing that too). I've never quite figured out
where the attitude that if I'm using an isp for internet access then I
should be happy using them for mail service also came about.

Sure, by all means, if you see someone sending an unusual amount of email
from an adsl line, investigate that. But don't expect me to stick around
and do business with you if you treat me as a second class citizen.

For the record, SBC's dsl started doing this (in michigan at least), and
started doing it without any advanced warning no less. But at least they
provided an option for letting you get exempted from the block.
James Ebright
2005-05-25 15:50:22 UTC
Permalink
Post by Ian Mitchell
Personally, I'm highly opposed to blocking outbound port 25. There
are some of us who don't have the resources to run a domain on a business
class line.
Where are you located at? We charge $5.00/mo for a single static ip which
would most likely work in your situation (We are in Sprint/Bellsouth ILEC
areas), Doesn't matter if you are DSL or Dial-up for that price (but a MTA on
the other side of a dialup.. yuck!). With dedicated circuits we usually
include a single or small block depending on the circuit (as most ILECS will
as well) after you justify the space allocation (we use ARINs forms since
thats what we need to fill out as well).
Post by Ian Mitchell
So by cutting our port 25, we are now forced to limit which domains
we can send email too. I have to add special rules to those specific
domains that choose to deny my emails to forward through my ISP's
MTA. The point of running an MTA is so you don't have to do that.
Running an MTA on the other side of dynamic IP space is usually a bad idea
unless you forward all of it through your providers MTA from your own (easy to
do in sendmail). Otherwise you will end up being blocked by a LARGE number of
providers using DNSBLs for dynamic IP space.
Post by Ian Mitchell
Post by James Ebright
* block outbound port 25 except for designated MTAs. Define a SPF record
for
said MTAs. Implement SMTP Auth.
Only if the email presents itself as being from that domain, if someone's
running a domain on an IP of that ISP, then that domain should have
an SPF record that SHOULD allow the emails to go through. I
advertise a hard SPF record for my domain, I allow email to only
come from my IP. Unfortunately due to the rules that I have to set
up for certian ISP's that limit port 25, I have to allow my ISP to
act as a relay in the SPF record as well. Not my most ideal
solution. But it's that kind of backwardness you get when people
start breaking things ;)
Wow, first off, are you rewriting your SPF records every time your IP updates
via the dynamic IP space via mydyndns.org? Your SPF record allows your current
dynamic IP as well as charter.com's SPF record if any (your cable provider).

Honestly, I would bet you are in violation of RFC2821 with regards to reverse
DNS requirements for a SMTP server, you are against the thought that your ISP
(charter) might (and most likely will) start blocking port 25 outbound and
that you might have to require your private MTA (rogue MTA) to relay all of
its outbound mail through charters mail servers, which is actually how it
should have been setup in the first place (and again, is pretty easy to do,
just involves a few mc file edits to hide your mta as the opriginator), and
claim all of this due to either your security expertise or to not being able
to afford a static IP assignment? Look at the bigger picture.

Also, I do hope you have a business account with charter as they specifically
forbid "servers" in their terms of service agreement for residential accounts.
Also, I know Cox Communications and Time Warner here both provide a single
static for no extra cost if you ask for a business account and pretty much all
of the DSL providers including my ISP do for business level DSL accounts and
can for residential for a small fee ($5.00/mo from us for a single static).

Sorry, I just can't help but shudder at the thought of running a businesses
MTA and MX of record over a dynamic IP using dyndns or any similar service,
esp since the risks are so high and the cost to do it right is probably about
the same you are paying to dyndns for their service.

Jim

--
EsisNet.com Webmail Client
Kenneth Porter
2005-05-25 18:14:06 UTC
Permalink
--On Wednesday, May 25, 2005 10:50 AM -0400 James Ebright
Post by James Ebright
Also, I do hope you have a business account with charter as they
specifically forbid "servers" in their terms of service agreement for
residential accounts.
Remember that "server" is not the same as "direct to MX" delivery. A server
to one's LAN can still be set up as only a client to the rest of the
Internet. This is pretty convenient for DNS and mail.
James Ebright
2005-05-25 18:37:52 UTC
Permalink
Post by Kenneth Porter
Remember that "server" is not the same as "direct to MX" delivery. A
server to one's LAN can still be set up as only a client to the rest
of the Internet. This is pretty convenient for DNS and mail.
Yes, but in that scenario the "client" is relaying ALL of the mail through the
ISPs mail server and not doing any direct-to-mta deliveries, which is what I
suggested he do in my first response. ;-)

Jim

--
EsisNet.com Webmail Client
Kenneth Porter
2005-05-25 19:10:38 UTC
Permalink
--On Wednesday, May 25, 2005 1:37 PM -0400 James Ebright
Post by James Ebright
Yes, but in that scenario the "client" is relaying ALL of the mail
through the ISPs mail server and not doing any direct-to-mta deliveries,
which is what I suggested he do in my first response. ;-)
The client *can* do that (just as it can relay all web traffic through an
ISP proxy), but it can also do direct to MX.

We could probably block some phishing if we forced all clients to go
through an ISP's web proxy and blocked access to "bad" sites there.
James Ebright
2005-05-25 18:42:49 UTC
Permalink
Post by Kenneth Porter
Remember that "server" is not the same as "direct to MX" delivery. A
server to one's LAN can still be set up as only a client to the rest
of the Internet. This is pretty convenient for DNS and mail.
Oh, let me clarify, by relay ALL mail I meant relay ALL OUTGOING email, local
deliveries need to be relayed and incoming deliveries would not be affected by
an ISP blocking port 25 outbound. (but mx via dynamic dns.... sounds risky if
you require email to do business).

Jim

--
EsisNet.com Webmail Client
WBrown at e1b.org ()
2005-05-25 15:33:52 UTC
Permalink
Post by Ian Mitchell
And third, one could use the argument that we should use hosting
services.

I use a hosting company for my personal domain and they don't support MSA,
so I'm stuck configuring Thunderbird to use SMTP to send outbound mail. My
employer acts as an ISP to school districts and we have been implementing
outbout SMTP filtering for about a month now, after I've nagged them for a
year or more. If they implement it on our building subnet, I'll be down
there asking for my static IP to be opened.
Albert Croft
2005-05-25 19:55:49 UTC
Permalink
7. Re: Re: Odd error messages filling up logfiles in new
deployment (MD 2.49 or 2.51) (David F. Skoll)
----------------------------------------------------------------------
Message: 7
Date: Tue, 24 May 2005 20:59:09 -0400
Subject: Re: [Mimedefang] Re: Odd error messages filling up logfiles in new deployment (MD 2.49 or 2.51)
mimedefang.pl -features
on the machine in question?
Seeing "-odd" -related messages means mimedefang.pl is having
trouble re-mailing messages. Could you post some complete log
excerpts _without_ obfuscating the e-mail addresses in question?
Regards,
David.
Here are the results of the command you asked for:

$ mimedefang.pl -features
MIMEDefang version 2.49

Archive::Zip : yes
File::Scan : yes
HTML::Parser : yes
HTML::TokeParser : yes
Net::DNS : yes
Path:CONFDIR : yes (/etc/mail)
Path:QUARANTINEDIR : yes (/var/spool/MD-Quarantine)
Path:SENDMAIL : yes (yes)
Path:SPOOLDIR : yes (/var/spool/MIMEDefang)
SpamAssassin : yes
Unix::Syslog : yes
Virus:CLAMAV : yes (/usr/bin/clamscan)
Virus:CLAMD : yes (/usr/sbin/clamd)
Virus:FileScan : yes
HTMLCleaner : no
Virus:AVP : no
Virus:AVP5 : no
Virus:BDC : no
Virus:CSAV : no
Virus:FPROT : no
Virus:FPROTD : no
Virus:FSAV : no
Virus:HBEDV : no
Virus:NAI : no
Virus:NVCC : no
Virus:OpenAV : no
Virus:SOPHIE : no
Virus:SOPHOS : no
Virus:SymantecCSS : no
Virus:TREND : no
Virus:TROPHIE : no
Virus:VEXIRA : no

Anomy::HTMLCleaner : missing
Archive::Zip : Version 1.14
Digest::SHA1 : Version 2.07
File::Scan : Version 1.43
HTML::Parser : Version 3.35
HTML::TokeParser : Version 2.28
IO::Socket : Version 1.28
IO::Stringy : Version 1.212
MIME::Base64 : Version 3.05
MIME::Tools : Version 5.417
MIME::Words : Version 5.417
Mail::Mailer : Version 1.21
Mail::SpamAssassin : Version 3.000001
Net::DNS : Version 0.48
Unix::Syslog : Version 0.100

I went back to 1.15 of Mail::Tools yesterday afternoon, but it has done
it with both that and the 1.67 versions.

Strangely, this morning it appears to have occurred once and corrected
itself (only dumping about 1.2GB of data into the logs). I am pasting
the beginning and ending (as best I can determine) of the event below.

5439 May 25 09:47:30 spam1b sendmail[12177]: j4PElA1d012177:
from=<***@mcwane.com>, size=297982, class=0, nrcpts=4,
msgid=<***@exchange.local.mcwanebham.com>,
proto=ESMTP, daemon=MTA, relay=nsc69.38.52-165.newsouth.net [69.38.52.165]
5440 May 25 09:47:30 spam1b mimedefang-multiplexor[7610]: stats
1117032450.941 StartFilter slave=3 nslaves=15 nbusy=3
5441 May 25 09:47:31 spam1b mimedefang-multiplexor[7610]: Slave 3
stderr: -f<***@mcwane.com> -odd -Ac -oi <***@TylerPipe.com>
-f<***@mcwane.com> -odd -Ac -oi <***@TylerPipe.com>
-f<***@mcwane.com> -odd -Ac -oi <***@TylerPipe.com>
-f<***@mcwane.com> -odd -Ac -oi <***@TylerPipe.com>
-f<***@mcwane.com> -odd -Ac -oi <***@TylerPipe.com>
-f<***@mcwane.com> -odd -Ac -oi <***@TylerPipe.com>
-f<***@mcwane.com> -odd -Ac -oi <***@TylerPipe.com>
-f<***@mcwane.com> -odd -Ac -oi <***@TylerPipe.com>
-f<***@mcwane.com> -odd -Ac -oi <***@Tyle
5442 May 25 09:47:31 spam1b mimedefang-multiplexor[7610]: Slave 3
stderr: rPipe.com> -f<***@mcwane.com> -odd -Ac -oi
<***@TylerPipe.com> -f<***@mcwane.com> -odd -Ac -oi
<***@TylerPipe.com> -f<***@mcwane.com> -odd -Ac -oi
<***@TylerPipe.com> -f<***@mcwane.com> -odd -Ac -oi
<***@TylerPipe.com> -f<***@mcwane.com> -odd -Ac -oi
<***@TylerPipe.com> -f<***@mcwane.com> -odd -Ac -oi
<***@TylerPipe.com> -f<***@mcwane.com> -odd -Ac -oi
<***@TylerPipe.com> -f<***@mcwane.com> -odd -Ac -oi
<***@TylerPipe.com> -f<***@mcwane.com> -odd -Ac -oi <J

... (repeated for all but 158 of the next 2,258,358 lines) ...

2263800 May 25 09:58:34 spam1b mimedefang-multiplexor[7610]: Slave 3
stderr: <***@mcwane.com> -odd -Ac -oi <***@TylerPipe.com>
-f<***@mcwane.com> -odd -Ac -oi <***@TylerPipe.com>
-f<***@mcwane.com> -odd -Ac -oi <***@TylerPipe.com>
-f<***@mcwane.com> -odd -Ac -oi <***@TylerPipe.com>
-f<***@mcwane.com>
-odd -Ac -oi <***@TylerPipe.com> -f<***@mcwane.com> -odd -Ac -oi
<***@TylerPipe.com> -f<***@mcwane.com> -odd -Ac -oi
<***@TylerPipe.com> -f<***@mcwane.com> -odd -Ac -oi
<***@TylerPipe.com> -f<***@mcwane.com> -odd -Ac -oi <***@TylerP
2263801 May 25 09:58:34 spam1b mimedefang-multiplexor[7610]: Slave 3
stderr: ipe.com> -f<***@mcwane.com> -odd -Ac -oi
<***@TylerPipe.com> -f<***@mcwane.com> -odd -Ac -oi
<***@TylerPipe.com> -f<***@mcwane.com> -odd -Ac -oi
<***@TylerPipe.com> -f<***@mcwane.com> -odd -Ac -oi
<***@TylerPipe.com> -f<***@mcwane.com> -odd -Ac -oi
<***@TylerPipe.com> -f<***@mcwane.com> -odd -Ac -oi
<***@TylerPipe.com> -f<***@mcwane.com> -odd -Ac -oi
<***@TylerPipe.com> -f<***@mcwane.com> -odd -Ac -oi
<***@TylerPipe.com> -f<***@mcwane.com> -odd -Ac -oi <JRe
2263802 May 25 09:58:34 spam1b mimedefang-multiplexor[7610]: Slave 3
stderr: ***@TylerPipe.com> -f<***@mcwane.com> -odd -Ac -oi
<***@TylerPipe.com> -f<***@mcwane.com> -odd -Ac -oi
<***@TylerPipe.com> -f<***@mcwane.com> -odd
2263803 May 25 09:58:34 spam1b mimedefang-multiplexor[7610]: Reap:
Killed slave 3 (pid 7643) exited due to SIGTERM/SIGKILL as expected.
2263804 May 25 09:58:34 spam1b mimedefang-multiplexor[7610]: Slave 3
resource usage: req=18, scans=18, user=5.171, sys=0.230, nswap=0,
majflt=3, minflt=11935, maxrss=0, bi=0, bo=0

I appreciate your time and consideration, and any assistance you can
provide.

Sincerely,
Albert C.
David F. Skoll
2005-05-25 20:31:41 UTC
Permalink
Post by Albert Croft
Path:SENDMAIL : yes (yes)
Oh, boy, do you have problems!! :-)

The path to Sendmail should be something like /usr/sbin/sendmail

For some reason, your installation thinks it is "yes". Most unfortunately,
there's a UNIX command called "yes"... well, go read the man page and
you'll see why your log is filling with millions of lines...

You need to convince MIMEDefang's "configure" script to find your Sendmail
executable correctly.

Regards,

David.
Matthew.van.Eerde at hbinc.com ()
2005-05-25 20:01:26 UTC
Permalink
Post by Gary Schrock
Blocking outgoing port 25 prevents me from using my own legit
business server at work.
That's what port 587 is for.
Post by Gary Schrock
(Ok, maybe if they don't block 587 also, but
let's face it, it's just a matter of time before isp's start doing
that too).
Why? Mail servers can be reasonably expected to require some kind of authorization to accept mail on port 587. So that port is useless for spammers, unless they can hijack your credentials. And if they can, at least the blame can be placed on your business, where it belongs. Your business will then likely lock your account until your machine can be cleaned.
--
Matthew.van.Eerde (at) hbinc.com 805.964.4554 x902
Hispanic Business Inc./HireDiversity.com Software Engineer
perl -e"map{y/a-z/l-za-k/;print}shift" "Jjhi pcdiwtg Ptga wprztg,"
Ian Mitchell
2005-05-25 20:14:16 UTC
Permalink
Date: Wed, 25 May 2005 10:50:13 -0400
Subject: Re: [Mimedefang] FTC asks ISPs to crack down on zombie PCs
Where are you located at? We charge $5.00/mo for a single static ip which
would most likely work in your situation (We are in Sprint/Bellsouth ILEC
areas), Doesn't matter if you are DSL or Dial-up for that price (but a MTA
on
the other side of a dialup.. yuck!). With dedicated circuits we usually
include a single or small block depending on the circuit (as most ILECS
will
as well) after you justify the space allocation (we use ARINs forms since
thats what we need to fill out as well).
I have two broadband options. Cable and satellite. And it's a matter of
picking your poisons at that point. I looked up dialup and no, I just
could not drag myself to suffering with a 56K connection. Not to mention,
it's damn hard to find Linux modems now-a-days.
Running an MTA on the other side of dynamic IP space is usually a bad idea
unless you forward all of it through your providers MTA from your own
(easy to
do in sendmail). Otherwise you will end up being blocked by a LARGE number
of
providers using DNSBLs for dynamic IP space.
I've been blocked by a few for dynamic DNS, but in general it works ok. I
can get through to the people I want to get through. Likewise, I'm pretty
picky which RBL's I use. If I'm listed, it's not used. The RBL's I use cut
down about 90% of the SPAM, where SA and Mimedefang snag the other 10%.
Wow, first off, are you rewriting your SPF records every time your IP
updates
via the dynamic IP space via mydyndns.org? Your SPF record allows your
current
dynamic IP as well as charter.com's SPF record if any (your cable
provider).
As for dynamic IP's, dyndns works wonders and yes, I do manually update my
SPF record, but that's not very difficult and could theoretically be done
through the same script that updates the IP. But since that only happens
about once a year or so, I'm not that motivated. Ironically, I don't get
many failures from SPF, I guess it's not as widely used as I'd like to
think. I support it, and I recomend others do as well. But my SPF record
was wrong for a long time and I didn't receive a single bounce because of
it.
Honestly, I would bet you are in violation of RFC2821 with regards to
reverse
DNS requirements for a SMTP server, you are against the thought that your
ISP
(charter) might (and most likely will) start blocking port 25 outbound and
that you might have to require your private MTA (rogue MTA) to relay all
of
its outbound mail through charters mail servers, which is actually how it
should have been setup in the first place (and again, is pretty easy to
do,
just involves a few mc file edits to hide your mta as the opriginator),
and
claim all of this due to either your security expertise or to not being
able
to afford a static IP assignment? Look at the bigger picture.
Definately in violation of RFC2821. But then again, I haven't seen much
impact on that. Honestly though, I doubt the ISP would be so willing to
release their rDNS record to me anyway ;)
Also, I do hope you have a business account with charter as they
specifically
forbid "servers" in their terms of service agreement for residential
accounts.
I do not have a business account, and have had servers running on them for
over 5 years now. Several techicians have been over before to test line
quality and each has noted my configuration. In my oppinion, if they wish
to specifically forbid them, then they should enforce it. I'm using their
services responsibly and haven't had an issue with them (other than their
really jacked up accounting department).
Also, I know Cox Communications and Time Warner here both provide a single
static for no extra cost if you ask for a business account and pretty much
all
of the DSL providers including my ISP do for business level DSL accounts
and
can for residential for a small fee ($5.00/mo from us for a single
static).
Be nice if they were available...
Sorry, I just can't help but shudder at the thought of running a
businesses
MTA and MX of record over a dynamic IP using dyndns or any similar
service,
esp since the risks are so high and the cost to do it right is probably
about
the same you are paying to dyndns for their service.
Wouldn't it be nice if my domain was business related ;)

Like I said, I can't pay business rates when there isn't a business. It's
a hobby. I get to play with real MTA's (10K+ emails per day) at work, and
yes, I do have technical ownership of the reverse DNS there ;)
Ben Kamen
2005-05-25 20:21:55 UTC
Permalink
Post by Ian Mitchell
I have two broadband options. Cable and satellite. And it's a matter of
picking your poisons at that point. I looked up dialup and no, I just
could not drag myself to suffering with a 56K connection. Not to mention,
it's damn hard to find Linux modems now-a-days.
I have a USR Courier V.everything modem I could sell ya.. (grin)
Heck, if THAT doesn't work. hahaha.. I hear ya there though. Everyhing in
WinModem these days.
Post by Ian Mitchell
Definately in violation of RFC2821. But then again, I haven't seen much
impact on that. Honestly though, I doubt the ISP would be so willing to
release their rDNS record to me anyway ;)
Well, in a sense they can't since they own the block - but sheesh, IT'S SO EASY
TO CHANGE A PTR RECORD even a ... well, ok, monkey's can't do it I guess... so
much for having 50,000 of them.

<groan>

-Ben
Kenneth Porter
2005-05-26 00:50:42 UTC
Permalink
--On Wednesday, May 25, 2005 2:14 PM -0500 Ian Mitchell
Post by Ian Mitchell
I have two broadband options. Cable and satellite. And it's a matter of
picking your poisons at that point.
Same here. And I take back my earlier assertion about price. I'd pay double
to get a static IP that I could legally run a server from. I just checked
http://work.comcast.net and the only "business" class service I can get
still doesn't let me have that, and yet the price is exorbitant.
Post by Ian Mitchell
I do not have a business account, and have had servers running on them for
over 5 years now. Several techicians have been over before to test line
quality and each has noted my configuration. In my oppinion, if they wish
to specifically forbid them, then they should enforce it. I'm using their
services responsibly and haven't had an issue with them (other than their
really jacked up accounting department).
I keep wondering why they don't just block SYN packets bound for customer
equipment. Accepting those packets is pretty much the definition of a
server, so blocking them would instantly enforce the TOS, at least for TCP.

I've got Speakeasy business ADSL at the office. If only I could get that at
home....
Kevin A. McGrail
2005-05-26 01:41:44 UTC
Permalink
Post by Kenneth Porter
I keep wondering why they don't just block SYN packets bound for customer
equipment. Accepting those packets is pretty much the definition of a
server, so blocking them would instantly enforce the TOS, at least for TCP.
Wouldn't that mess with P2P software, FTP and more?
Ian Mitchell
2005-05-25 20:42:00 UTC
Permalink
Date: Wed, 25 May 2005 19:44:49 +0200
Subject: Re: [Mimedefang] FTC asks ISPs to crack down on zombie PCs
Can you broaden my vision of thing and give some exemples where the
hoster's smtp server and the ISP smtp server is not enough so you would
want to use your own internal smtp server to send emails from a
dsl/cable line ? As far as my short sight see the only reason i see is
hidding behing unstable ip and fairly untrackable source (yes this is
fairly limited but meant to make people react and enlighten me rather
than drop this mail to the trashcan :) ?
Privacy. TLS encryption from MTA to MTA through the ISP is a good example.
And as for hiding. There's not much hiding involved. Tools like netcraft
do a good job at tracking all the IP's I've ever used. Further more, the
ISP keeps logs (or atleast they SAY they do) of all the IP's assigned via
DHCP. So there's not much hiding involved. Primarily, it's privacy. Now,
if 25 inbound was shut down (which I could see an ISP doing) then I would
seriously be in trouble because there'd be no inbound email any longer.
Any way if the use are limited i think changing the habbit of a
minority toi protect the internet as a whole is a good trade off :)
I disagree.
Sure, by all means, if you see someone sending an unusual amount of email
from an adsl line, investigate that. But don't expect me to stick around
and do business with you if you treat me as a second class citizen.
Agreed!
For the record, SBC's dsl started doing this (in michigan at least), and
started doing it without any advanced warning no less. But at least they
provided an option for letting you get exempted from the block.
BTW, I noticed SBC in the Houston area seemed to start adding their
systems behind a firewall and started issuing private IP's (172.16-32.x.x)
for their addresses. Is that the case? Or are they doing that for specific
problem children?
James Ebright
2005-05-26 18:24:04 UTC
Permalink
Post by Ian Mitchell
Privacy. TLS encryption from MTA to MTA through the ISP is a good example.
You can still run your own MTA, just it should forward all outbound mail to
the ISP MTA and not attempt any direct to MTA deliveries. If you have TLS
setup and your ISP has TLS capabilities it will remained encryted the entire
way, it will even remain encrypted if the recieving end has TLS too, if the
recieving end doesnt then you dont loose anything cause your own MTA woudl
have dropped it as well (the encryption that is).
Post by Ian Mitchell
And as for hiding. There's not much hiding involved.
You need to rewrite the envelope if you do not have your own domain, if you do
then you just need to make sure your MX is your MTA, simple.
Post by Ian Mitchell
Further more,
the ISP keeps logs (or atleast they SAY they do) of all the IP's
assigned via DHCP.
They do and it is probably in radius logs, not DHCP, they are actually
required to keep them for a period of time, I have the last 3 months here on
the live filesystem and have ALL of them archived. I have had cases where the
FBI or local SBI subpeonaed our records to find out what customer was on a
certain IP address at a given time.
Post by Ian Mitchell
So there's not much hiding involved.
You cannot hide from your ISP, they know who you are.... ;-)
Post by Ian Mitchell
Now, if 25 inbound was shut down (which I could see an
ISP doing) then I would seriously be in trouble because there'd be
no inbound email any longer.
Why would an ISP shutdown port 25 inbound? I see no logical reason to do so,
spam does not get delivered directly to a users desktop (at this time at
least). The zombies are not controlled via port 25 inbound (at least any I
have seen). In other words, I know of no good reason to shutdown port 25
inbound... now port 25 outbound, yes, definately for dynamic IP space.


Jim

--
EsisNet.com Webmail Client
Kelsey Cummings
2005-05-26 18:58:52 UTC
Permalink
Post by James Ebright
Post by Ian Mitchell
Now, if 25 inbound was shut down (which I could see an
ISP doing) then I would seriously be in trouble because there'd be
no inbound email any longer.
Why would an ISP shutdown port 25 inbound? I see no logical reason to do so,
spam does not get delivered directly to a users desktop (at this time at
least). The zombies are not controlled via port 25 inbound (at least any I
have seen). In other words, I know of no good reason to shutdown port 25
inbound... now port 25 outbound, yes, definately for dynamic IP space.
You must block port 25 in both directions to prevent 'triangular routing
attacks' from working.
--
Kelsey Cummings - ***@sonic.net sonic.net, inc.
System Architect 2260 Apollo Way
707.522.1000 (Voice) Santa Rosa, CA 95407
707.547.2199 (Fax) http://www.sonic.net/
Fingerprint = D5F9 667F 5D32 7347 0B79 8DB7 2B42 86B6 4E2C 3896
James Ebright
2005-05-26 20:05:37 UTC
Permalink
Post by Kelsey Cummings
You must block port 25 in both directions to prevent 'triangular routing
attacks' from working.
We are not running any type of mobile IP here nor IPv6 and while yes, this
type of attack is possible with IPv4, TCP provides some protection against
this attack:

If the target address belongs to a real node, it will respond with TCP
Reset, which prompts CN to close the connection.

If target is a non-existent address, the target network may send ICMP
Destination Unreachable messages. Not all networks send this latter kind of
error messages.

The attack is not specific to MIPv6:

Dynamic updates are made to Secure DNS, there is no requirement or
mechanism for verifying that the registered IP addresses are true.

ICMP Redirect messages enable a similar attack on the scale of a local
network. We expect there to be other protocols with the same type of
vulnerability.

And I know for sure both Cisco routers and Linux boxes send ICMP Dest.
Unreachable messages for non existant addresses.

I am not saying we are fool proof, but this attack seems unlikely enough to
succeed that is it would be unreasonable for us inconvenience to our customer
base by blocking port 25, not to mention we would probably detect it as a
potential DOS attack via our IDS fairly quickly anyway simply due to the
latency/traffic it would cause.

Jim
--
EsisNet.com Webmail Client
James Ebright
2005-05-26 20:16:36 UTC
Permalink
Post by James Ebright
I am not saying we are fool proof, but this attack seems unlikely
enough to succeed that is it would be unreasonable for us
inconvenience to our customer base by blocking port 25, not to
mention we would probably detect it as a potential DOS attack via
our IDS fairly quickly anyway simply due to the latency/traffic it
would cause.
This should read port 25 incoming... /sigh/ returned from vacation, still
catching up on sleep as well as email. ;-)

Jim
--
EsisNet.com Webmail Client
Kelsey Cummings
2005-05-26 21:04:36 UTC
Permalink
Post by James Ebright
Post by Kelsey Cummings
You must block port 25 in both directions to prevent 'triangular routing
attacks' from working.
...
Post by James Ebright
I am not saying we are fool proof, but this attack seems unlikely enough to
succeed that is it would be unreasonable for us inconvenience to our customer
base by blocking port 25, not to mention we would probably detect it as a
potential DOS attack via our IDS fairly quickly anyway simply due to the
latency/traffic it would cause.
'People in the Know' claim that this is in widespread useage already. I
am presonally only parroting what I've heard from very reputable sources.
--
Kelsey Cummings - ***@sonic.net sonic.net, inc.
System Architect 2260 Apollo Way
707.522.1000 (Voice) Santa Rosa, CA 95407
707.547.2199 (Fax) http://www.sonic.net/
Fingerprint = D5F9 667F 5D32 7347 0B79 8DB7 2B42 86B6 4E2C 3896
John Nemeth
2005-05-26 01:16:48 UTC
Permalink
On Oct 15, 11:26am, Kenneth Porter wrote:
}
} I keep wondering why they don't just block SYN packets bound for customer
} equipment. Accepting those packets is pretty much the definition of a
} server, so blocking them would instantly enforce the TOS, at least for TCP.

There goes active FTP and possibly other protocols...

}-- End of excerpt from Kenneth Porter
John Nemeth
2005-05-26 03:45:27 UTC
Permalink
On Oct 15, 3:17pm, "Kevin A. McGrail" wrote:
}
} > I keep wondering why they don't just block SYN packets bound for customer
} > equipment. Accepting those packets is pretty much the definition of a
} > server, so blocking them would instantly enforce the TOS, at least for
} > TCP.
}
} Wouldn't that mess with P2P software, FTP and more?

Yep. However, P2P software would count as servers. Besides, ISPs
really hate P2P software, since it consumes great gobs of bandwidth
(the number one application currently on the Internet), so I doubt they
would worry about it. FTP, on the other hand, is a valid concern,
since it would mess with FTP clients in active mode. Simplistic
answers have a tendency to have many problems.

}-- End of excerpt from "Kevin A. McGrail"
Kenneth Porter
2005-05-26 04:25:23 UTC
Permalink
--On Wednesday, May 25, 2005 7:45 PM -0700 John Nemeth
Post by John Nemeth
FTP, on the other hand, is a valid concern,
since it would mess with FTP clients in active mode. Simplistic
answers have a tendency to have many problems.
Two rules then: Allow FTP SYN's, and block all other SYN's. Are there any
other "non-server" uses for inbound SYN?
David F. Skoll
2005-05-26 04:55:06 UTC
Permalink
Post by Kenneth Porter
Two rules then: Allow FTP SYN's, and block all other SYN's.
You cannot detect "FTP SYNs" because in active-mode FTP, the FTP
client is free to choose an ephemeral port for the reverse connection.

I don't think ISPs should prevent people from running "servers",
because that's far too wide a concept. I would get most annoyed if my
ISP blocked my OpenVPN traffic, for example, even though there's an
SSH "server" running over the VPN traffic. (I'm lucky enough to live
in Canada, where you can generally find a decent ISP that gives out
reasonably-priced static addresses and lets clueful users do what they
need.)

ISPs should do the following:

- Block outbound port 25 connections except to their own mail servers.

- Insist on SMTP AUTH for outbound mail. Perhaps then even block outbound
port 25 completely and force port 587.

- Monitor traffic from customer equipment to detect the telltale signs of
virus infection or spamming.

That's all. Blocking ALL servers is too draconian.

Regards,

David.
Kelsey Cummings
2005-05-26 08:01:36 UTC
Permalink
Post by David F. Skoll
- Block outbound port 25 connections except to their own mail servers.
Yes.
Post by David F. Skoll
- Insist on SMTP AUTH for outbound mail. Perhaps then even block outbound
port 25 completely and force port 587.
Yes.
Post by David F. Skoll
- Monitor traffic from customer equipment to detect the telltale signs of
virus infection or spamming.
This is alot easier said then done at scale. (But not impossible, just
quite hard and expensive, especially for the big little ISP.)
Post by David F. Skoll
That's all. Blocking ALL servers is too draconian.
What about blocking the ports that are common vectors like NetBIOS, etc.?

-Kelsey
David F. Skoll
2005-05-26 14:14:06 UTC
Permalink
Post by Kelsey Cummings
Post by David F. Skoll
- Monitor traffic from customer equipment to detect the telltale signs of
virus infection or spamming.
This is alot easier said then done at scale.
That's true, unfortunately.
Post by Kelsey Cummings
Post by David F. Skoll
That's all. Blocking ALL servers is too draconian.
What about blocking the ports that are common vectors like NetBIOS, etc.?
I would block common vector ports by default, but open them up if
(1) the customer pays for a static IP address and (2) the customer
requests them to be open.

Regards,

David.
Kelsey Cummings
2005-05-26 17:49:22 UTC
Permalink
Post by David F. Skoll
Post by Kelsey Cummings
Post by David F. Skoll
That's all. Blocking ALL servers is too draconian.
What about blocking the ports that are common vectors like NetBIOS, etc.?
I would block common vector ports by default, but open them up if
(1) the customer pays for a static IP address and (2) the customer
requests them to be open.
Hey - that's exactly what we do for DSL. Users can select between 4
settings, no filters, smtp blocking, 'common ports', all inbound (non
established) blocked.
--
Kelsey Cummings - ***@sonic.net sonic.net, inc.
System Architect 2260 Apollo Way
707.522.1000 (Voice) Santa Rosa, CA 95407
707.547.2199 (Fax) http://www.sonic.net/
Fingerprint = D5F9 667F 5D32 7347 0B79 8DB7 2B42 86B6 4E2C 3896
Matthew.van.Eerde at hbinc.com ()
2005-05-26 19:09:14 UTC
Permalink
Post by Kelsey Cummings
Now, if 25 inbound was shut down...
Why would an ISP shutdown port 25 inbound?...
You must block port 25 in both directions to prevent 'triangular
routing attacks' from working.
What is a triangular routing attack?
--
Matthew.van.Eerde (at) hbinc.com 805.964.4554 x902
Hispanic Business Inc./HireDiversity.com Software Engineer
perl -e"map{y/a-z/l-za-k/;print}shift" "Jjhi pcdiwtg Ptga wprztg,"
Kelsey Cummings
2005-05-26 20:11:00 UTC
Permalink
Post by Matthew.van.Eerde at hbinc.com ()
Post by Kelsey Cummings
Now, if 25 inbound was shut down...
Why would an ISP shutdown port 25 inbound?...
You must block port 25 in both directions to prevent 'triangular
routing attacks' from working.
What is a triangular routing attack?
Take host A, zombie B, and target C.

Host A is hosted on a high speed link with a spam-friendly or clueless ISP
that does not implement RPV and allows spoofed traffic to leave their
network.

A sources traffic usings B's IP address to C on port 25.
C sends ACKs to B from port 25, B forwards ACKs to A.

This allows the spammer to send spam out via fast links while only using
their zombie networks to process the ACKS.

Blocking traffic sent *from* port 25 into subscribers is as important as
blocking outbout port 25 traffic from them. Of course, make sure your own
mail servers are allowed to send their responses.
--
Kelsey Cummings - ***@sonic.net sonic.net, inc.
System Architect 2260 Apollo Way
707.522.1000 (Voice) Santa Rosa, CA 95407
707.547.2199 (Fax) http://www.sonic.net/
Fingerprint = D5F9 667F 5D32 7347 0B79 8DB7 2B42 86B6 4E2C 3896
WBrown at e1b.org ()
2005-05-26 19:15:13 UTC
Permalink
Post by James Ebright
Post by Ian Mitchell
Privacy. TLS encryption from MTA to MTA through the ISP is a good
example.
Post by James Ebright
You can still run your own MTA, just it should forward all outbound mail
to
Post by James Ebright
the ISP MTA and not attempt any direct to MTA deliveries. If you have
TLS
Post by James Ebright
setup and your ISP has TLS capabilities it will remained encryted the
entire
Post by James Ebright
way, it will even remain encrypted if the recieving end has TLS too, if
the
Post by James Ebright
recieving end doesnt then you dont loose anything cause your own MTA
woudl
Post by James Ebright
have dropped it as well (the encryption that is).
If you TLS to the ISP's mail server, the ISP can still snoop the contents
(or let Big Brother have a copy if they supeona it.)
Post by James Ebright
Post by Ian Mitchell
So there's not much hiding involved.
You cannot hide from your ISP, they know who you are.... ;-)
Which is why the trick is to encrypt the traffic until it gets past the
ISP's reach. Look up "onion routing."
Post by James Ebright
Why would an ISP shutdown port 25 inbound? I see no logical reason to do
so,
Post by James Ebright
spam does not get delivered directly to a users desktop (at this time at
least). The zombies are not controlled via port 25 inbound (at least any
I
Post by James Ebright
have seen). In other words, I know of no good reason to shutdown port 25
inbound... now port 25 outbound, yes, definately for dynamic IP space.
To kill mail servers sitting inside their network (in violation of the
TOS). Adelphia did this to me. I didn't mind so much blocking inbound
port 80, but 25 rally honked me off!
James Ebright
2005-05-26 20:07:58 UTC
Permalink
Post by WBrown at e1b.org ()
If you TLS to the ISP's mail server, the ISP can still snoop the contents
(or let Big Brother have a copy if they supeona it.)
Only if they have a copy of your certificate and key.....

Of course if the end destination is there then they can look at the final
delivered message.

Jim
--
EsisNet.com Webmail Client
Matthew.van.Eerde at hbinc.com ()
2005-05-26 19:57:59 UTC
Permalink
Post by WBrown at e1b.org ()
Post by James Ebright
Why would an ISP shutdown port 25 inbound?
To kill mail servers sitting inside their network (in violation of the
TOS). Adelphia did this to me. I didn't mind so much blocking
inbound port 80, but 25 rally honked me off!
You mean, it didn't bother you when they shut down the web server that you put up in violation of their terms of service... but it did bother you when they shut down the mail server that you put up in violation of their terms of service?

o_O

Or am I misunderstanding?
--
Matthew.van.Eerde (at) hbinc.com 805.964.4554 x902
Hispanic Business Inc./HireDiversity.com Software Engineer
perl -e"map{y/a-z/l-za-k/;print}shift" "Jjhi pcdiwtg Ptga wprztg,"
WBrown at e1b.org ()
2005-05-26 20:14:33 UTC
Permalink
Post by Matthew.van.Eerde at hbinc.com ()
Post by WBrown at e1b.org ()
To kill mail servers sitting inside their network (in violation of the
TOS). Adelphia did this to me. I didn't mind so much blocking
inbound port 80, but 25 rally honked me off!
You mean, it didn't bother you when they shut down the web server
that you put up in violation of their terms of service... but it did
bother you when they shut down the mail server that you put up in
violation of their terms of service?
Exactly. I'm a mail geek, not a web geek. I moved my personal domain to
a hosting company and the web page I have up there looks worse than most
of the pages you see on angelfire or tripod.


Q. Why doesn't Microsoft make vacuum cleaners?
A. Because they wouldn't suck.
WBrown at e1b.org ()
2005-05-26 20:20:42 UTC
Permalink
Post by James Ebright
Post by WBrown at e1b.org ()
If you TLS to the ISP's mail server, the ISP can still snoop the
contents
(or let Big Brother have a copy if they supeona it.)
Only if they have a copy of your certificate and key.....
Ummm wouldn't TLS only encrypt the traffic between the two servers
involved at the moment, ie, your mail server and theirs as you relay
though it? Encrypting the contents of the message would keep it out of
their hands.
James Ebright
2005-05-26 20:48:32 UTC
Permalink
Post by WBrown at e1b.org ()
Ummm wouldn't TLS only encrypt the traffic between the two servers
involved at the moment, ie, your mail server and theirs as you relay
though it? Encrypting the contents of the message would keep it out
of their hands.
It encrypts the transmission of the message(s) from MUA through to Final
Delivery MTA Assuming every MTA in the middle can handle TLS, once a non TLS
MTA is hit from there on it is regular ole plaint text.

Jim
--
EsisNet.com Webmail Client
Josh Kelley
2005-05-26 21:22:41 UTC
Permalink
Post by James Ebright
Post by WBrown at e1b.org ()
Ummm wouldn't TLS only encrypt the traffic between the two servers
involved at the moment, ie, your mail server and theirs as you relay
though it? Encrypting the contents of the message would keep it out
of their hands.
It encrypts the transmission of the message(s) from MUA through to Final
Delivery MTA Assuming every MTA in the middle can handle TLS, once a non TLS
MTA is hit from there on it is regular ole plaint text.
Sorry, I don't think this is correct:

My MUA doesn't know the final delivery MTA, so it can't encrypt a
message for viewing by the final delivery MTA only. Instead, it uses
TLS to encrypt the entire SMTP conversation with my local MTA. My local
MTA then takes the plaintext message and passes it on to the next MTA in
the delivery chain. If the next MTA supports TLS, then the message is
re-encrypted, passed across the wire as part of an encrypted SMTP
conversation, and again decrypted by the next MTA. And so on to the
final location. TLS encrypts traffic across the wire, but each MTA in
the chain sees the message.

Like WBrown said, if you don't want ISPs reading your mail, encrypt the
messages, don't rely on TLS.

This is at least my understanding. If I'm missing something, please let
me know.

Josh Kelley
James Ebright
2005-05-26 22:27:38 UTC
Permalink
Post by Josh Kelley
My MUA doesn't know the final delivery MTA, so it can't encrypt a
message for viewing by the final delivery MTA only. Instead, it
uses TLS to encrypt the entire SMTP conversation with my local MTA.
My local MTA then takes the plaintext message and passes it on to
the next MTA in the delivery chain. If the next MTA supports TLS,
then the message is re-encrypted, passed across the wire as part of
an encrypted SMTP conversation, and again decrypted by the next MTA.
And so on to the final location. TLS encrypts traffic across the
wire, but each MTA in the chain sees the message.
Well, I am not sure 100%, most of my info on this is from several orielly
books and the only one in front of me atm is the network security hacks one
which does describe TLS like I did above, but...

I believe that sendmail uses Diffie-Hellman key exchange and the MTA only
keeps the master_secret in memory for a short period of time and must be
redetermined during every conversation, so technically yes, I think a middle
MTA could see it, but it would be alot more work than I would be willing to
put in to see it in real time. I suppose you could modify the source to store
unencrypted local copys and mirror that in real time.... but I can think of
other easier ways to get copies of your outgoing email if I really wanted them
(like say for a court ordered subpeona).

If the data is that sensative then use a third party encryption on the message
itself or dont send it via email.

Jim
--
EsisNet.com Webmail Client
Kris Deugau
2005-05-26 23:03:15 UTC
Permalink
Post by James Ebright
I believe that sendmail uses Diffie-Hellman key exchange and the MTA
only keeps the master_secret in memory for a short period of time and
must be redetermined during every conversation, so technically yes, I
think a middle MTA could see it, but it would be alot more work than
I would be willing to put in to see it in real time. I suppose you
could modify the source to store unencrypted local copys and mirror
that in real time.... but I can think of other easier ways to get
copies of your outgoing email if I really wanted them (like say for a
court ordered subpeona).
Hmm. I think you're still a little confused.

TLS is really a generic method for encrypting communication between two
arbitrary systems. It does NOT specify what's done with the data at
either end. (Think HTTPS, or POP3S, or IMAPS- technically, AIUI, all
use TLS.)

What it prevents (or at least significantly guards against) is capture
of the TCP/IP packet stream (even at either system's local kernel level)
by a third party. The sending system and receiving system are
essentially running standard SMTP otherwise; and any of the standard
methods of pulling data out of the MTA at either end should work just
fine.

It's important not so much to prevent capture of the message data -
although it helps to some degree there - but with preventing capture of
somewhat more sensitive data such as SMTP AUTH tokens of several
flavours. It's also of rather limited use as an authenication system in
and of itself with the right certificates.
Post by James Ebright
If the data is that sensative then use a third party encryption on
the message itself or dont send it via email.
Yep. *Really* high-security data shouldn't be on a network that's
Internet-connected, period, IMO; and if you need to transfer data you
stuff it on a USB key or hard drive and take the physical device from
network A to network B. (If you're really paranoid, you destroy the
physical transport device once you've pulled the data.)

For most data that should be secured, but which is MUCH more conventient
to handle online? PGP. (Or GPG, or whatever PGP-equivalent you feel
like using.)

-kgd
--
Get your mouse off of there! You don't know where that email has been!
WBrown at e1b.org ()
2005-05-26 21:07:56 UTC
Permalink
Post by James Ebright
It encrypts the transmission of the message(s) from MUA through to Final
Delivery MTA Assuming every MTA in the middle can handle TLS, once a non
TLS
Post by James Ebright
MTA is hit from there on it is regular ole plaint text.
thanks for the explanation.
John Nemeth
2005-05-28 20:39:05 UTC
Permalink
On Oct 15, 2:20pm, ADNET Ghislain wrote:
}
} > Agreed. I wouldn't be opposed to blocking port 25 if there were a way
} > to get it unblocked for the clueful, like a web page that takes
} > someone slightly more savvy than a monkey to navigate, and that you
} > don't get free help to fill in. (Maybe require the user to solve a
} > sendmail rule puzzle!)
}
} imho the cluefull people use a real server in a hosting center or use
} professional contract with ISP that allow them to have such rules,

How about clueful people that are trying to do it on a budget. I
built and run the mail servers for two service providers. The largest
one handles about 20,000 incoming messages per day and easily rivals
the broadband providers for reliability. I know what I'm doing.
However, both service providers are dial-up. I use a broadband service
provider at home. My server at home is just as well maintained and
reliable as any ISP (perhaps more so). Why shouldn't I run it there?
I will grant you that the average home user doesn't have a clue, but
that's not true for all.

} personnal adsl lines should not have such options. Little users should
} use the ISP smtp server or any cheap hosting server that comme with it.
} I do not see why you would use your own adsl or cable modem link to send
} emails. Obviously if you can receive emails for your domain you can also

Because I can do it better then the service providers. Some of
these big companies are great at providing bandwidth, but not so great
at running services.

} send them as it requires a domain name and therefor a pop/smtp server ?

I have my own domain name. They're cheap. I also have a POP
server (accessible only from within the house) and an SMTP server. I'm
thinking of converting the latter to sendmail X. The house is a place
I can play without worrying about killing production systems; although,
to some degree the house is a production system.

} Can you broaden my vision of thing and give some exemples where the
} hoster's smtp server and the ISP smtp server is not enough so you would

Lousy service. Just want to do it myself, since I am fully
capable of doing it.

} want to use your own internal smtp server to send emails from a
} dsl/cable line ? As far as my short sight see the only reason i see is
} hidding behing unstable ip and fairly untrackable source (yes this is

My dynamic IP is more stable then static IPs from the same service
provider. My IP very rarely changes. If you're a small organisation
with only one address, you can expect it to move around periodically,
even if it is "static". Also, it is quite trackable.

} fairly limited but meant to make people react and enlighten me rather
} than drop this mail to the trashcan :) ?

Trolls should be dropped in the trashcan regardless of their
intentions.

} Any way if the use are limited i think changing the habbit of a
} minority toi protect the internet as a whole is a good trade off :)

Wrong! This is an extremely slippery slope. We should not be
sacrificing useful functionality because of some miscreants. We need
to figure out how to thump the latter very hard. Repealing CAN-SPAM
and replacing it with something that has real teeth would be a good
thing.

}-- End of excerpt from ADNET Ghislain
John Nemeth
2005-09-13 14:37:43 UTC
Permalink
On Feb 3, 3:35am, "Kevin A. McGrail" wrote:
}
} Joseph Brennan was kind enough to share more code snippets with me which had
} predisposed me against a bounce. BUT Joseph's code was originally done in
} filter_begin which led to my initial worry about reject/bounce vs discard.
}
} However, right now, I am thinking I should be able to do the invalid helo
} and invalid MX check in filter_sender since I have $sender and that's all I
} need. If I reject in filter_sender, I haven't received the entire email yet
} and it isn't a very "costly" transaction.

If you do the test in filter_sender() then a discard would
definitely be more expensive since that would force you to receive the
message; whereas with a reject you wouldn't even have to look at the
recipients much less receive the message.

}-- End of excerpt from "Kevin A. McGrail"
Kevin A. McGrail
2005-09-13 15:25:48 UTC
Permalink
Post by John Nemeth
} However, right now, I am thinking I should be able to do the invalid helo
} and invalid MX check in filter_sender since I have $sender and that's all I
} need. If I reject in filter_sender, I haven't received the entire email yet
} and it isn't a very "costly" transaction.
If you do the test in filter_sender() then a discard would
definitely be more expensive since that would force you to receive the
message; whereas with a reject you wouldn't even have to look at the
recipients much less receive the message.
I am looking more towards using these tests in filter_sender and if they
fail, to return a 5XX level Rejection for Invalid MX Record so I think we
are on the same page.

Regards,
KAM
Les Mikesell
2005-09-13 15:43:44 UTC
Permalink
Post by Kevin A. McGrail
Post by John Nemeth
} However, right now, I am thinking I should be able to do the invalid
helo
Post by John Nemeth
} and invalid MX check in filter_sender since I have $sender and that's
all I
Post by John Nemeth
} need. If I reject in filter_sender, I haven't received the entire email
yet
Post by John Nemeth
} and it isn't a very "costly" transaction.
If you do the test in filter_sender() then a discard would
definitely be more expensive since that would force you to receive the
message; whereas with a reject you wouldn't even have to look at the
recipients much less receive the message.
I am looking more towards using these tests in filter_sender and if they
fail, to return a 5XX level Rejection for Invalid MX Record so I think we
are on the same page.
If the only or best MX target is 127.0.0.1, this is fairly hostile
toward your neighbor relay. But, as I mentioned before, the spam
appliance I am forwarding through is doing a 451 temp_fail which
just prolongs the problem and backs up my queue. There's no chance
that a notification is going to make it anywhere in this case
so why not drop it? On the other hand if there are multiple
targets and some appear good, it might make sense to reject/bounce.

A logical extension of this would be some way to parse your logs
for repeated failures for bounce delivery attempts and add those
to the bad address list.
--
Les Mikesell
***@futuresource.com
Kevin A. McGrail
2005-09-13 16:35:06 UTC
Permalink
How is this a hostile to the relay? We aren't even accepting the mail. We
are rejecting it before the conversation between the SMTP servers is
finished. This email won't even hit your local queue.
Post by Les Mikesell
If the only or best MX target is 127.0.0.1, this is fairly hostile
toward your neighbor relay. But, as I mentioned before, the spam
appliance I am forwarding through is doing a 451 temp_fail which
just prolongs the problem and backs up my queue. There's no chance
that a notification is going to make it anywhere in this case
so why not drop it? On the other hand if there are multiple
targets and some appear good, it might make sense to reject/bounce.
A logical extension of this would be some way to parse your logs
for repeated failures for bounce delivery attempts and add those
to the bad address list.
Les Mikesell
2005-09-13 16:57:10 UTC
Permalink
Post by Kevin A. McGrail
How is this a hostile to the relay? We aren't even accepting the mail. We
are rejecting it before the conversation between the SMTP servers is
finished. This email won't even hit your local queue.
It's unlikely you are talking to the original sender. Assume a
forwarding relay has accepted a copy (as I am doing now), then
trying to deliver. If you give a 5xx smtp response you force the
sending relay to construct a bounce. But you know it's impossible
to deliver it.

--
Les Mikesell
***@futuresource.com
Kevin A. McGrail
2005-09-13 18:05:05 UTC
Permalink
OK, then I would agree that if you do not have an MD box on the edge of your
network, you should discard. Otherwise, you should reject. I'm going under
the assumption that there is no middle-man relay and I'm trying to save my
resources by rejecting prior to receiving the entire message.

To discard, you will need to perform the tests in filter_begin.

Regards,
KAM
----- Original Message -----
From: "Les Mikesell" <***@futuresource.com>
To: <***@lists.roaringpenguin.com>
Sent: Tuesday, September 13, 2005 11:51 AM
Subject: Re: [Mimedefang] MX -> 127.0.0.1
Post by Les Mikesell
Post by Kevin A. McGrail
How is this a hostile to the relay? We aren't even accepting the mail.
We
Post by Les Mikesell
Post by Kevin A. McGrail
are rejecting it before the conversation between the SMTP servers is
finished. This email won't even hit your local queue.
It's unlikely you are talking to the original sender. Assume a
forwarding relay has accepted a copy (as I am doing now), then
trying to deliver. If you give a 5xx smtp response you force the
sending relay to construct a bounce. But you know it's impossible
to deliver it.
Matthew.van.Eerde at hbinc.com ()
2005-09-13 16:48:22 UTC
Permalink
Post by Kevin A. McGrail
Post by Les Mikesell
If the only or best MX target is 127.0.0.1, this is fairly hostile
toward your neighbor relay. But, as I mentioned before, the spam
appliance I am forwarding through is doing a 451 temp_fail which
just prolongs the problem and backs up my queue. There's no chance
that a notification is going to make it anywhere in this case
so why not drop it? On the other hand if there are multiple
targets and some appear good, it might make sense to reject/bounce.
How is this a hostile to the relay? We aren't even accepting the
mail. We are rejecting it before the conversation between the SMTP
servers is finished. This email won't even hit your local queue.
This depends entirely on your SMTP topology. There is no absolute answer. It depends what part of the SMTP server universe is "yours", where you do your checking, and on your personal philosophy.
--
Matthew.van.Eerde (at) hbinc.com 805.964.4554 x902
Hispanic Business Inc./HireDiversity.com Software Engineer
Matthew.van.Eerde at hbinc.com ()
2005-09-13 17:44:07 UTC
Permalink
Post by Les Mikesell
Post by Kevin A. McGrail
How is this a hostile to the relay? We aren't even accepting the
mail. We are rejecting it before the conversation between the SMTP
servers is finished. This email won't even hit your local queue.
It's unlikely you are talking to the original sender. Assume a
forwarding relay has accepted a copy (as I am doing now), then
trying to deliver. If you give a 5xx smtp response you force the
sending relay to construct a bounce. But you know it's impossible
to deliver it.
Assumptions, assumptions.

I am perfectly comfortable bouncing because...

* I scan inbound mail only.
Outbound mail is NOT scanned.

* I scan on my MX hosts.
I do NOT accept mail on any server under my control prior to scanning.

However, if either of the preceding were false (as they are for Les,) there would be a very strong case against action_bounce indeed. action_discard would start to look very good, particularly if the outgoing queue was a bottleneck.
--
Matthew.van.Eerde (at) hbinc.com 805.964.4554 x902
Hispanic Business Inc./HireDiversity.com Software Engineer
Jim McCullars
2005-09-13 19:33:42 UTC
Permalink
Post by Les Mikesell
Post by Kevin A. McGrail
How is this a hostile to the relay? We aren't even accepting the mail. We
are rejecting it before the conversation between the SMTP servers is
finished. This email won't even hit your local queue.
It's unlikely you are talking to the original sender. Assume a
forwarding relay has accepted a copy (as I am doing now), then
trying to deliver. If you give a 5xx smtp response you force the
sending relay to construct a bounce. But you know it's impossible
to deliver it.
If the forwarding relay cannot construct a bounce, it really has no
business accepting the mail in the first place. Besides, just because you
cannot deliver a bounce, that doesn't mean the forwarding relay cannot.
An internal DNS, or mailertable are two ways that it could.

Jim McCullars
University of Alabama in Huntsville
Les Mikesell
2005-09-13 20:05:47 UTC
Permalink
Post by Jim McCullars
Post by Les Mikesell
It's unlikely you are talking to the original sender. Assume a
forwarding relay has accepted a copy (as I am doing now), then
trying to deliver. If you give a 5xx smtp response you force the
sending relay to construct a bounce. But you know it's impossible
to deliver it.
If the forwarding relay cannot construct a bounce, it really has no
business accepting the mail in the first place.
None of us here can determine that yet or we wouldn't be talking
about how to do it... Isn't it a bit much to expect everyone else to
already be checking?
Post by Jim McCullars
Besides, just because you
cannot deliver a bounce, that doesn't mean the forwarding relay cannot.
An internal DNS, or mailertable are two ways that it could.
Anyone who has gone to the trouble of poisoning public DNS with an
MX that ends up at 127.0.0.1 really doesn't want that bounce back
so I think we can assume they won't make an extra effort to make it
work from certain machines. Or, they just want to cause trouble
for others and it becomes your choice to help them or not.
--
Les Mikesell
***@futuresource.com
Matthew.van.Eerde at hbinc.com ()
2005-09-13 20:28:08 UTC
Permalink
Post by Les Mikesell
Post by Jim McCullars
Post by Les Mikesell
It's unlikely you are talking to the original sender. Assume a
forwarding relay has accepted a copy (as I am doing now), then
trying to deliver.
Depending on your topology, that "assumption" may be a certainty - or it may be a jump to conclusions.
Post by Les Mikesell
Post by Jim McCullars
Post by Les Mikesell
If you give a 5xx smtp response you force the
sending relay to construct a bounce. But you know it's impossible
to deliver it.
Only given the assumption above. If the sending agent is NOT a relay, but is instead the sending domain's MSA, then the bounce message will be constructed and delivered directly to the sender without any need for further SMTP at all. Exchange works like this, for example.
Post by Les Mikesell
Post by Jim McCullars
If the forwarding relay cannot construct a bounce, it really has
no business accepting the mail in the first place.
None of us here can determine that yet or we wouldn't be talking
about how to do it... Isn't it a bit much to expect everyone else to
already be checking?
http://www.digital-sledgehammer.com/superchicken/sounds/dangerous.wav
Post by Les Mikesell
Post by Jim McCullars
Besides, just because you
cannot deliver a bounce, that doesn't mean the forwarding relay
cannot. An internal DNS, or mailertable are two ways that it could.
Anyone who has gone to the trouble of poisoning public DNS with an
MX that ends up at 127.0.0.1 really doesn't want that bounce back
so I think we can assume they won't make an extra effort to make it
work from certain machines. Or, they just want to cause trouble
for others and it becomes your choice to help them or not.
Maybe they put it in by mistake. Bouncing at least gives them a hint.
--
Matthew.van.Eerde (at) hbinc.com 805.964.4554 x902
Hispanic Business Inc./HireDiversity.com Software Engineer
Les Mikesell
2005-09-13 21:36:55 UTC
Permalink
Post by Matthew.van.Eerde at hbinc.com ()
Post by Les Mikesell
Anyone who has gone to the trouble of poisoning public DNS with an
MX that ends up at 127.0.0.1 really doesn't want that bounce back
so I think we can assume they won't make an extra effort to make it
work from certain machines. Or, they just want to cause trouble
for others and it becomes your choice to help them or not.
Maybe they put it in by mistake. Bouncing at least gives them a hint.
Am I supposed to believe that someone who sets up:

liyuanculture.com mail exchanger = 10 nullmx.liyuanculture.com.
and
Name: nullmx.liyuanculture.com
Address: 127.0.0.1

did it accidentally, yet they might have a private DNS that works
correctly and that user ***@liyuanculture.com really cares
about getting that notification message even if were possible
to deliver it?
--
Les Mikesell
***@futuresource.com
Matthew.van.Eerde at hbinc.com ()
2005-09-13 22:20:31 UTC
Permalink
Post by Les Mikesell
Post by Matthew.van.Eerde at hbinc.com ()
Post by Les Mikesell
Anyone who has gone to the trouble of poisoning public DNS with an
MX that ends up at 127.0.0.1 really doesn't want that bounce back
so I think we can assume they won't make an extra effort to make it
work from certain machines. Or, they just want to cause trouble
for others and it becomes your choice to help them or not.
Maybe they put it in by mistake. Bouncing at least gives them a
hint.
liyuanculture.com mail exchanger = 10 nullmx.liyuanculture.com.
and
Name: nullmx.liyuanculture.com
Address: 127.0.0.1
did it accidentally, yet they might have a private DNS that works
about getting that notification message even if were possible
to deliver it?
Heh. No, you are not supposed to believe that. :)

Also, this case
http://www.exim.org/pipermail/exim-users/Week-of-Mon-20040412/069931.html
is rapidly falling out of favor. In fact, ibase.com has fixed that somewhat.

I'm worried in particular about the novice Exchange admin who has misconfigured his Active Directory DNS records.
--
Matthew.van.Eerde (at) hbinc.com 805.964.4554 x902
Hispanic Business Inc./HireDiversity.com Software Engineer
Ben Kamen
2005-09-13 22:36:51 UTC
Permalink
Post by Matthew.van.Eerde at hbinc.com ()
Also, this case
http://www.exim.org/pipermail/exim-users/Week-of-Mon-20040412/069931.html
is rapidly falling out of favor. In fact, ibase.com has fixed that somewhat.
I'm worried in particular about the novice Exchange admin who has misconfigured his Active Directory DNS records.
WOW what a weird set of records...

Definitely a novice admin... most likely MCSE certified. ;)

Seriously, we see this and wonder why when the IT world underpays for real
talent like it does?

The dichotomy is: "It's windows, it's so easy to use because it's graphical and
your secretary likes it" while also saying you need an MCSE to really know how
to use windows cause apparently it's that complex....

Well which is it Mr. Gates? Complex or easy? ;)

So what the employer doesn't understand is that the concepts are hard, no matter
what OS you're running it on - thus, you can't scale pay like your secretary
could run your network services.

I love metaphors:

It's like building an F16 by microsoft, putting a novice pilot in it and saying
"it'll be ok - they'll do fine - there's only one big pretty red button in the
cockpit labeled *kill bad guys*"
John Nemeth
2007-11-14 08:59:36 UTC
Permalink
On Apr 6, 2:57am, ADNET Ghislain wrote:
} ADNET Ghislain a =E9crit :
} > David F. Skoll a =E9crit :
} >> Steffen Kaiser wrote:
} >>
} >>> Actually, this is a sendmail question, but I don't think that it is
} >>> possible.
} >>
} >> Well, in filter_sender, you can return 'ACCEPT_AND_NO_MORE_FILTERING'
} >> which turns off all subsequent milter calls. So you can't avoid
} >> milter completely, but you can avoid the really expensive calls.
} >>
} in fact my test reveal that the smtp auth info is not in filter sender.
}
} I use
}
} if (defined($SendmailMacros{"auth_type"})) {
} md_syslog('warning',"smtp auth ");
} return ('ACCEPT_AND_NO_MORE_FILTERING', "ok");
} }
} if ($RelayAddr eq "127.0.0.1") {
} md_syslog('warning', "smtp 127.0.0.1");
} return ('ACCEPT_AND_NO_MORE_FILTERING', "ok");
} }
}
} for local mail it work in filter_sender but it does not for sendmail=20
} auth. I duplicated this in filter_end and it work there :)

Macros aren't automatically read in for filter_sender() and
filter_rcpt(). You need to add "read_commands_file();" near the top of
filter_sender to have macros read in.

}-- End of excerpt from ADNET Ghislain
ADNET Ghislain
2007-11-14 09:27:35 UTC
Permalink
Post by John Nemeth
Macros aren't automatically read in for filter_sender() and
filter_rcpt(). You need to add "read_commands_file();" near the top of
filter_sender to have macros read in.
}
oh ! yes it works now. Thanks a lot for pointing this, seems that i
missed it in the man page. thanks also to Steffen Kaiser for the same
hint :)
--
Cordialement,
Ghislain
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3518 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.roaringpenguin.com/pipermail/mimedefang/attachments/20071114/eaaf400f/smime.bin
Loading...