ietf-smtp
[Top] [All Lists]

Re: stupid SMTP rejection of spammers

2001-06-16 02:34:15

At 14.02 -0400 01-06-15, Keith Moore wrote:
 > Start by writing a paper about "BCP of SMTP operation".

 (1) Don't block empty envelope from:
(2) Don't say ok to a recipient address if you are not 100% sure you can do
 local delivery.
 (3) ...


any others that folks want to contribute?

Keith

Loop control could be discussed, but there may be difficulty
to reach consensus, since there are different techniques which
all work (and can be combined for increased reliability).

See the quote at the end of this e-mail from my
not-yet-published book about application layer protocols. You
have my permission to use part of this text. Loop control
can of course be needed also without mailing lists,
especially when Sendmail aliases are used or other
auto-retransmission tools.

Should your document on SMTP behaviour:

(a) Incorporate my paper about mailing list behaviour,
    see http://dsv.su.se/jpalme/ietf/mailing-list-behaviour.txt

(b) Leave mailing list behaviour to my paper.

(c) Duplicate information from my mailing list behaviour
    paper.

You are free to use the content of my paper on mailing
list behaviour.

--- --- quote from not-yet-published-book --- ---

1.12.2 Loop control for nested mailing lists

If two lists are directly or indirectly members of each
other, there is a risk that the same message will be looped
back and forward indefinitely between the lists. There are
several different techniques for avoiding this:

(1)     Full expansion by the originating UA.

(2a)    A trace list of all the mailing lists passed is put
on the envelope of the message. A mailing list can then
refuse to accept, incoming messages, that have the name of
the mailing list itself as part of the trace list on the
envelope of the message.

(2b)    Using a variant of method (2a), each mailing list
will instead refuse to send a message to another mailing list
which is included in the trace list of the message.

(3)     The registration system for mailing lists is designed
in such a way that no list will ever be a member, directly or
indirectly, of itself.

(4a)    Each mailing list stores the message-IDs of all
messages passing through
the list. When the same message returns once more to the
list, the list checks the message-ID of the message and stops
the loop if a message with the same ID has already passed
through the list. (Message-ID is also known under the term
Message-ID.)

(4b)    This is a variant of method (4a), where a checksum of
the content of the message is used instead of the message-ID.

The X.400 standard for electronic mail uses method (2a) and
recommends use of method (2b) as an addition to (but not as a
replacement for) method (2a). The advantage of method (2b)
is that it saves some unnecessary transmission. However,
method (2b) is not as reliable as method (2a), because the
same electronic mail address can have different forms, and
therefore the comparison used in method (2b) may not work. It
is easier for a list expander to recognize a name which it
itself puts on an envelope than a name which some other list
expander puts on an envelope.

Comparing methods (4a) and (4b), method (4b), use of a
checksum, has the advantage that it caters for systems where
the message-ID is corrupted (something which is not unusual),
but has as a disadvantage that two different messages may
accidentally get the same checksum. A further problem with
the message-ID is that two messages with the same message-ID
may not always be identical. Finally, some mail systems to
not generate globally unique message-IDs on the messages
they produce.

Method (4a) is often used by computer conferencing systems,
sometimes combined with the other methods. For example,
Usenet News mainly uses method (4a).
Programs that send messages through gateways from Internet
e-mail to Usenet News will assign Message-IDs to messages
lacking such IDs. This can cause the same message to get
different Message-IDs by different gateways.

The Listserv software has very powerful methods for avoiding
loops, primarily based on method (4b).

In practice, many existing mailing lists have no loop control
mechanism except that the people who manage the list manually
try to avoid producing loops.

--
--
Jacob Palme <jpalme(_at_)dsv(_dot_)su(_dot_)se> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/