× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



[cc:ed to midrange-nontech; please send any replies there.]

* Brad Jensen <brad@elstore.com> [2001-11-22 01:23 -0600]:
> If he is not using SMTP passwords (and the normal state is not to
> require them) then anyone can connect to him and send mail thru
> him. Unless he does IP filtering.

Not necessarily true.  You are describing what is termed an open relay and
the default setting of sendmail was as you describe for many years.  Now,
however, sendmail and most other mail servers will not relay by default.
What this means, specifically, is that the mail server will look at the
destination email address.  If that address is not at a domain the server
has been told to accept mail for, it will simply reject the attempt.  No
IP filtering is needed.

You are perhaps thinking of the situation where a mail server must relay
some email, but not necessarily all of it.  An example of this would be an
ISP that provides a mail server for its customers to send their mail
though.  In this case, some IP filtering or other approach is usually
taken to limit the server's relaying to valid clients.  This is still not
an open relay, though it does take a little more setup than the default
settings.

> As I said before, if you use the SMTP servers in their normal
> state according to the RFCs, you are allowing anyone to connect to
> you  and send mail, unless you do IP filtering. If you do use a
> password on the SMTP connection, you are going beyond the RFCs.

SMTP is defined in RFC 2821.  Section 3.7 says, among other things, "The
relay server may accept or reject the task of relaying the mail in the
same way it accepts or rejects mail for a local user."  The RFC says
nothing about having to accept email.  For the most part, it merely
defines SMTP, leaving the actual mail servers to decide what to do with
the data received via SMTP.

In addition, RFC 2554 defines an extension to SMTP that enables password
authentication.

RFC 2505 discusses anti-spam measures to be taken on mail servers,
including the closing of open relays.

For my example of an ISP which relays only for valid clients, RFC 2645
discusses a mechanism for on-demand mail relaying.

> Some people, upset with this, have started using programs that
> probe ip addresses on the web for a functioning SMTP server. They
> then try to connect to your mail server as an SMTP client or as an
> SMTP server asking your server to relay mail. If your server
> follows the rules and lets them attach, they mark your server as a
> potential spam source, even if it has not been used for this.

Yes.  Because the rules do not mandate running an open relay and other
sources highly recommend against it.  (RFC 2505 is a "Best Current
Practice" document and is thus not technically a source of "rules".)

> Technically speaking, the people creating these lists are hacking
> your server, and compounding that by interfering with
> acommunication by wire.

That's a very fine distinction.  Most people would say that if the server
is running and accessible from the Internet, it's ok to connect to it and
attempt to send an email through.  Certainly it's possible to abuse
services such as these, but their intended purpose is to send email.  As
for the blacklisting, it has its own problems, but they are only lists.
Sites that use those lists as a basis for accepting or rejecting email do
so voluntarily--no one is forcing them.

For the record, while I support the right of these lists to exist, I don't
use them myself.  I feel that, for me and the servers I operate, the
possibility of false positives (valid email coming from a server being
marked as possible spam) is more of a hindrance than dealing with the
actual spam I receive.

> One of these lists targeted one of my servers a year or so ago,
> and a certain university still wont pass email to me even to this
> day. We 'fixed' (actually broke, in terms of the RFC) our servers
> to conform to the extortion by the black holers as soon as we
> became aware of the problem a year or so ago.

Your servers should still be able to fulfill their purpose--delivering
email to people validly served by them.  In addition, your servers should
also now be less spammer-friendly (while still being standards-compliant;
see the RFCs I mentioned above).

> And no matter what their wonderful intentions are, the guys who
> did this are outlaws.

As should be evident by now, I respectfully disagree with you.
Admittedly, some of the measures undertaken in the name of eradicating
spam are worse than the spam itself, but blackhole lists are used
voluntarily and most people (including myself) would not construe a
one-email test for open relaying as an abuse of resources.


As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.