At 00:18 2006-03-21 -0800, Wm. Vance wrote:
In which case you should disable the MTA from relaying. Problem solved.
Ok, how?
Use the access db in sendmail. Or disable the SMTP interface outright in
the sendmail.mc file (from which the sendmail.cf is generated) - remove the
MAILER(`smtp') line from the config.
You might even enable some DNSBLs. Though if you firewall the standard MTA
ports from getting into your net (as it sounds like you might have done -
25 and the lesser known 587), people outside your net won't be able to send
stuff to sendmail. This is probably an acceptable solution if you're not
accepting SMTP traffic from the outside world (as you're getting mail from
your primary MX via UUCP). It would affect your own ability to send mail
from the outside world, but as I indicated previously, you can use an SSH
tunnel with port forwarding.
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.
If you properly implement SMTP auth, encryption capability comes along for
the ride, and it's based on documented standards. Interoperability is a
good thing.
I know what a filter is, whats a milter?
A mail filter extension, introduced a few years back in Sendmail.
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
[snip]
So that would mean using popmail and other networking stuff?
Well, popmail would be a matter between you and your own mailhost. The
connection between your mail server (SMTP) and your upline provider
(celestial) would be SMTP. When "tickled" with an ETRN, their SMTP server
would go "oh, the primary MX is online and would like us to pump their
queue to them." Think of it sort of like an answering service - when
you're offline, they pick up after so many rings, and when you get back
into the office (your host is back online), you call them up and ask for
your messages.
Celestial doesn't provide networking services, just uucp. It's part of
their security setup.
That would be "security by obscurity" ? UUCP is a bit dated for a mail
transport. Mail is arriving at their servers via SMTP - there really isn't
any good argument for why they can't pass it along to you using the same
protocol - it managed it's way across the internet and into their hands
without any special protections. Heck, if they're so security concious,
they could implement TLS on the connection between their server and yours -
providing identify authentication and encryption of the connection as they
pass the message to your server.
TLS is yet another facility you'd have if you implemented SASL Auth on your
host...
---
Sean B. Straw / Professional Software Engineering
Procmail disclaimer: <http://www.professional.org/procmail/disclaimer.html>
Please DO NOT carbon me on list replies. I'll get my copy from the list.
____________________________________________________________
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