On Mon, 2003-03-10 at 17:31, Joe Polk wrote:
> Most ISP's don't allow send, only receive. Otherwise, they'd have to
> allow relaying for just about everyone which is where the bulk of spam
> traffic comes from.
This is widely quoted, however, sadly incorrect. Most ISP's only allow
receive and not send primarily due to ignorance, stupidity, or laziness,
or a combination of two or more of the above.
Sendmail (and surely most/all other mail servers) can be configured to
use SMTP AUTH, an open Internet standard where the server requires a
username and password to be supplied before anyone can send mail. This
permits a configuration where relaying is totally closed (as regards
per-subnet or per-IP relaying) but all legitimate users can send mail.
Again, every mail client I know supports this.
Passwords sent for SMTP AUTH can be simply Base64-encoded or encrypted.
Using the LOGIN or PLAIN mechanisms (i.e. simply encoding the password)
provides minimal security, but is still far better than POP3/IMAP/FTP
which send passwords in the clear.
With only minimal effort, CRAM-MD5 or DIGEST-MD5 encryption can be used
wherein the password is truly encrypted. Sendmail (and again, surely
other servers) also supports transactions over TLS/SSL so the entire
data stream (including user/pass) is encrypted.
Bottom line: my home sendmail has allowed AUTHenticated relaying for
well over three years now IIRC, with not a single spam sent through it
and static relaying firmly closed. And my ISP still does not AUTH. Sad.
Please note that, in my usual setup (and I run a webhosting business
with clients who travel, at last count, to 66 countries), ALL
transactions are required to AUTH... even those coming from "trusted"
subnets. NO ONE gets a free relay. Works quite well.
> Typically, you would set your server and clients behind a fw or
> something on a private address scheme, then just relay for the
> local subnet. That would avoid the relaying denied error.
Valid.
In this particular case, your Sendmail is rejecting the relay since the
reverse DNS (134.173.132.184 --> host.domain.com) is not working. That
is enough for Sendmail to reject it.
1. Set up internal DNS (forward and reverse). I'll be happy to
supply working files.
2. Set up SMTP AUTH. Can also supply my sendmail.mc or
instructions. This is simply too easy, and should IMHO
always be done.
3. Ten minutes later, live happily ever after.
You could also:
4. Set your firewall to redirect all SMTP connections
(regardless or source or destination) to your Sendmail
server.
5. Allow only SMTP from that one server through to the
outside.
6. Set up CRAM-MD5 and DIGEST-MD5 authentication so you
have true encryption instead of just encoding.
7. Set up TLS/SSL to encrypt all transport for SMTP.
8. Set up TLS/SSL to encrypt all transport for POP3/IMAP.
I'm guessing this would put you well within the top 5% (maybe 1%?)
most-secure SMTP sites out there. Steps #4, #5, and #6 are also pretty
darned easy and should (with instructions) take only another 10 or 15
minutes as well.
P.S. Guys and gals, can we PLEASE trim some of the unnecessary bits of
old messages, signatures, and list-footers from messages? THANK you...
--
Rodolfo J. Paiz <[EMAIL PROTECTED]>
--
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]
https://listman.redhat.com/mailman/listinfo/redhat-list
