> On Tue, 25 Mar 2008 03:14:12 GMT D. Stussy
bde-arc.ampr.org> wrote:
> | "daviddavid" emailmedia.com.au> wrote in message
> |> | ...
> | 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.
However, be aware that the last published "best current practice" and last
published standards disagree with the view presented in the paragraph above.
Use the advice at your own risk.
> 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.
If only such were universally possible. The fact is that it's not.
> 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.
Please also note that the callback system is not universally acceptable.
There are some that consider it abuse.
