× 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.



Roger Vicker, CCP wrote:
> I am not so sure about the ISP being brain-dead. Part of making sure a
> crud isn't using their network to spam or phish is to make sure the from
> address (not the HELO/ELHO envelope) is from a domain the ISP "knows"
> should be coming from their IP range. 

Requiring the from address to match the servers address is totally
invalid.  The FROM address is totally irrelevant except to the human
reader.  The server shouldn't care one lick about that.

Heck I would guess that 90% of the servers in the world send mail for
other domains domains in addition to the one their IP resolves to.  My
own mail server will happily send mail on behalf of a dozen different
domains (some my own, others cooperative relay agreements with other
groups).

Let's clarify something here ... there are two key parts of mail headers
... the FROM address and the SENDER address.  Usually they are the same,
but often they are different.  If you look at a mailing list message
you'll see that the FROM address is the original author, but the sender
address is associated with the mailing list software.  If a mail server
is concerned about any address it should be the sender address.

Now there *IS* a effort to start validating that a server is authorized
to send mail for a domain.  It's called SPF (http://spf.pobox.com/) ...
the theory is that a domain sets up some information in their DNS that
identifies what mail servers they send from.  Then, when mail is send
from a domain, the DNS is checked and validated.

>>Only brain-dead spam-blocking requires the HELO/ELHO name and/or rDNS
>>to match the sending domain.  Spam-blocking shouldn't even require
>>HELO/ELHO to match rDNS.
> And yet one of the widest used (I believe even David uses it for the
> lists) blockers is SpamAssassin and it uses HELO vs rDNS as one of its
> series of tests.

Yes, I use spamassassin ... and it does do checks of that nature.  But
spamassassin uses a series of checks that are cumulative ... each test
being assessed a score.  If the score is above a certain value it will
be classified as spam.  Additionally, spamassassin does not actually
block mail ... it only scores it.  It's up to the end user to discard
mail that matches a certain score.

> Just thought of another problem with the ISP blindly passing everything
> that comes from their IP range. Ex-employee (or just someone) gets an
> address close to a commercial customer, sets their mail program to use a
> from address of the commercial customer and sends a bunch of destructive
> email. How does anyone, without the audit ablity I have been harping on,
> prove it didn't come from a current "home worker" of the commercial
> customer. It didn't come from the commercial customer's server, but it
> doesn't have to to be legitimate because the ISP says that home workers
> can't use the commercial customer's server that does use authentication.

I'm not sure I understand what you are talking about here ... do you
mean address spoofing?  It's absolutely trivial for me to send email on
behalf of anyone else.  But if you look at the mail headers it will be
clear that it didn't come from the company I'm spoofing.

This is no different than an employee stealing letter-head before
quitting and sending paper mail pretending to represent the company.


david

-- 
David Gibbs
david@xxxxxxxxxxxx

Receipt of this message does not grant you permission to send me
Unsolicited Commercial Email


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

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.