|
|
 Up |
|
|
  |
| Re: confused about Backscatter listing |
|
 |
|
 |
|
 |
|
 |
Group: news.admin.netabuse.blocklisting · Group Profile
Author: phil-news-nospamphil-news-nospam Date: Mar 26, 2008 05:54
On Tue, 25 Mar 2008 03:14:12 GMT D. Stussy bde-arc.ampr.org> wrote:
| "daviddavid" emailmedia.com.au> wrote in message
| news:13928430-aed7-4414-bb4a-50bfa043a673@u10g2000prn.googlegroups.com...
|> I was referred to this website by UCE Protect, after being advised
|> (via a third party) that my IP address had been blacklisted.
|>
|> My problem is that I don't understand the information provided on the
|> UCE Protect site, nor on the backscatter site, and I don't know how to
|> go about fixing the problem.
|>
|> I do manage several large email lists using the affected domain (using
|> ezmlm and qmail) which were set up for me by a contract technician. I
|> have been managing these lists, using the same software (via various
|> upgrades, obviously), for more than 10 years - so I am a bit surprised
|> to find myself listed (according to the UCE Protect site, I have been
|> listed three or four times previously).
|>
|> I would like to fix whatever it is I am doing that is causing the
|> problem, but I can't work out what I am doing wrong. I don't know what
|> 'backscatter' or 'sender callouts' are (even after reading all the
|> documentation and doing a google search), but as far as I know I am
|> not using such devices.
|>
|> Our business is strictly 'non-spam' and highly ethical. But we are a
|> very small (husband and wife) business located in a semi-rural area of
|> Australia, which means it is hard to access up to date IT advice - and
|> the email lists are critical to our business.
|>
|> Can someone suggest a simple website which might explain what we have
|> done wrong, and how we can fix it?
|
| Chances are that you have probably done NOTHING wrong and are in fact
| following the current electronic mail standards. However, there seem to be
| some out there that have chosen to penalize systems for doing so - by trying
| to hold systems to a different set of standards, completely unwritten, and
| under the guise of combatting the spam problem. The issue is that their
| standards permit penalization of hosts which follow the Internet-wide
| published standards.
Be aware that merely following formal standards DOES NOT mean that you
are doing what is ACCEPTABLE PRACTICE on the internet. The standards
allow a wide range of practices because they focus on common functionality.
You can be following the standards to the letter and still be carrying on
a very unacceptable activity.
They do things like specify that the characters "RCPT" in an SMTP message
means that the email address string of the receipient is coming on the
same line. If you used "BLAH" instead, you would not be folloring the
standard for SMTP and other mail servers that do follow the standard
would not be able to successfully communicate with you.
What is acceptable practice is a more difficult notion. One reason it is
more difficult is there are so many different ideas of what it is. What
you need to do is GET INVOLVED in forums about the various activities in
running email servers so you can see what is going on.
In particular, one thing that is going on is that spammers are usually
forging someone else's email address in the spam they try to send. When
the spam attempt is made to certain mail servers, those servers ASSUME
the return email address is valid, and if the mail cannot be delivered,
will initiate a new message (often with the contents of the spam within)
and send it to the named email address WHICH IS NOT THE TRUE SENDER of
the email that could not be delivered.
The standards have established some protocols which allow your mail server
to make a determination of whether or not the SMTP peer trying to send your
server a message is in fact (one of) a valid sender for the domain used in
the return address on that message. There are two things your mail server
can decide on with the information obtained (which may not always be as
conclusive as you would like). It can decide whether or not to accept and
deliver the incoming email to the named recipient. In cases where that
email cannot be delivered for whatever reason, it can decide whether or not
to send a delivery status notification (DSN) back to the supposed sender
named in the message.
What is critical to understand is that the information gathered does NOT
mean those two decisions must always be the same thing. When information
tends to be ambiguous, these two decisions may be different under acceptable
practices. In particular, the decision to send the DSN should err on the
side of NOT disturbing someone whose email address was forged. It is this
decision (about sending DSN) that is affected by acceptable practice since
in impacts others. The other decision, whether or not to deliver email
that can be delivered, is up to you and your policies, since it genrally
does not affect others on the internet. You may choose to accept email in
cases where for non-deliverable messages you SHOULD NOT send a DSN.
An even easier way to be sure you do not send a DSN when you should not is
to configure your mail servers (possibly changing software) so that it NEVER
sends DSNs, but instead, completes the delivery determination during the
SMTP session and rejects an undeliverable message instantly. Then it is
the responsibility of the sending server to notify the sending person about
the problem. Under this "safe harbor" method, the only DSN that would ever
be sent is to YOUR OWN USERS who send outgoing email that another mail server
told you could not be delivered. And your mail server can validate these
senders through the use of an encrypted email submission protocol (not SMTP
itself) and username/login/password authentication. So such DSNs would not
be triggered by a spammer except in cases where a spammer takes control of
the computer of one of your users. You need to be sure your network has a
strong policy of informing users of their responsibility to keep their own
computers secure, and the penalties for failing to do so.
This "backscatter" spam is a very large problem. Some spammers use the same
email address on an entire spam run, or in some cases many spam runs. This
can result in MILLIONS of DSNs making their way back to a SINGLE INNOCENT
user, bombarding potentially a SINGLE INNOCENT mail server (even if the
username part of the address varied while the domain part does not).
The "callouts" are somewhat less of a problem because they are not a piece
of email that can clog up a mailbox. But they are a form of loading on a
mail server that is not only needless, but may even be triggering antispam
measures that could result in your own outgoing mail being undeliverable
when it should be deliverable. The practice is fundamentally flawed since
it cannot ever be universally deployed in a consistent way by all mail
servers and networks. It can also cause an overload on an innocent mail
server as a result of a spammer doing a spam run with a forged sender email
address. It needs to be shut off.
A "callout" is when a mail server pretends to be sending email back to the
supposed sender just to see if the sender is valid. This is unnecessary
since the only real test needed is to see if the email is coming from a
mail server that is authoritative to send for the user. If it is, it is
safe to assume the sending mail server authenticated the user.
--
|---------------------------------------/----------------------------------|
| Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
| first name lower case at ipal.net / spamtrap-2008-03-26-0810@ipal.net |
|------------------------------------/-------------------------------------|
|
|
|
|
|
|
|
|
|
|
