On Mon Mar 20 19:49:16 2006 Professional Software Engineering wrote:
At 17:23 2006-03-20 -0800, Wm. Vance wrote:
Is this the appropriate thing to do given the problem you are describing?
No.
Why not? It would permanently lose all spam/virii/etc., trying to reach
other systems through mine. As far as the internet is concerned, this is
basically a leaf node, and shouldn't have to worry about relaying anyway.
In which case you should disable the MTA from relaying. Problem solved.
Ok, how?
If you actually have a solution to eliminate all spam and viruses, you
should market it, then you'd be rolling in money.
I didn't say it would eliminate all of it, just those trying to get through my
system, to other systems, using the mail. That would be the reason for
removing the header line before sending the mail out; I.e., so the spammers et
al, couldn't discover what my system was uses for its, "magic", header line, or
even that thats what its doing.
It would help if I had the foggiest notion of how to do any of that.
Not everybody knows how to overhaul their cars engine either, but if you've
got a problem with a piston, that's what you do - or send it out to a pro
to deal with it. You don't pour "JoeBob's Ring Restorer and Snake Oil"
into the engine and expect it to actually work.
Or perhaps you do. But you shouldn't be surprised when it doesn't.
Unfortunately, being stuck on Social Security Disability, with lots of
bills, means I'm not going to be able to deal with it for some time to come.
That's unfortunate, but doesn't really have much bearing on the correct
solution to an email relaying problem at the MTA level though.
Part of my solution so far, has been to block outside access through my
router. Something I'd overlooked through ignorance.
Don't overlook possible (probable?) vulnerable scripts on a
webserver. "formmail.pl" is a common one.
Your source IP is a broadband IP from verizon.net. There are entire DNSBLs
dedicated to blocking crap which issues directly from consumer broadband
[snip]
Verizon is the phone company here. Unfortunately, I have to sign up for the
year to get the mildly cheaper rate.
Hey, I'm merely pointing out that the consumer broadband network IP
assignments (and their dialups too) are frequently blacklisted. Same goes
for SBC, SWbell, gte, earthlink, etc. Consumer connections to the internet
are the #1 source of both spam and malware - they represent an enormous
number of systems, but most importantly, generally operated by totally
CLUELESS folk who have no comprehension of computer security. In my book,
there's absolutely NO legit reason someone should be connecting to any of
my mailhosts from a consumer broadband connection - they should be relaying
mail through their own ISP mailhost and THEN to me. If they're a user of
my network, they'll present authentication credidentials.
I'm not sure, but I think with Verizon/GTE, the people who run the DSL hardware,
are the same ones who run their IP servers, same outfit, different dept.
Oh yeah, I'm doing UUCP over TCP to pick up my mail on an hourly basis.
I get it - you're on a dynamic IP and all that, but there are
solutions... Why not issue an ETRN to your upline mail provider and have
them set up as a mail secondary?
I don't even know what an ETRN is.
You might read up on some of this stuff before considering sendmail hacking
(which is what you'll have to do in order to inject procmail processing on
all your SMTP traffic). There's a (dated) writeup on getting sendmail to
run procmail on all OUTBOUND traffic.
Arguably, if you want to do some sendmail tweakage, you should consider
writing a sendmail milter. Even if you want to invoke procmail, that'll be
a more convenient approach anwyay. The non-milter approach (as documented
on my site) is rather painful...
I know what a filter is, whats a milter?
The seaslug part of my addr, is the Seattle
Unix Users Group, which is hosted by Celestial Systems. They're a fairly
busy commercial outfit, and I'm not sure they'd even want to consider it,
as they have their own, fairly complex security issues to deal with.
They're your PRIMARY MX now, according to DNS. All you'd really do is set
them up to be SECONDARY (i.e. put your own host at a lower MX cost). ETRN
is a rather standard SMTP command - you can find it in the SMTP RFCs, and
shelling to their server on port 25 then issuing the appropriate commands
would confirm that they support it. The fetchmail package has an option to
issue an ETRN, and your one real technical hurdle is ensuring that your
dynamic DNS updates properly. If you're on a fixed IP (not a periodically
tweaking DHCP), then you're pretty much home free. Dynamic DNS sites
should have more info for you (if you're using one).
So that would mean using popmail and other networking stuff? Celestial doesn't
provide networking services, just uucp. It's part of their security setup.
FTR, you're on the same IP you were yesterday (71.113.117.186), which is a
plus, but isn't a sure sign that your IP is static. xpresso doesn't have
an A record for your host - merely MX records (pointing to celestial).
It's dynamic, but it doesn't change very often, just if I'm down for a while.
Bill
____________________________________________________________
procmail mailing list Procmail homepage: http://www.procmail.org/
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail