ietf-smtp
[Top] [All Lists]

Re: Bounce/System Notification Address Verification

2005-06-28 09:50:40


----- Original Message -----
From: "Keith Moore" <moore(_at_)cs(_dot_)utk(_dot_)edu>
To: "Robert A. Rosenberg" <hal9001(_at_)panix(_dot_)com>
Cc: <moore(_at_)cs(_dot_)utk(_dot_)edu>; <ietf-smtp(_at_)imc(_dot_)org>
Sent: Tuesday, June 28, 2005 11:10 AM
Subject: Re: Bounce/System Notification Address Verification


OTOH: There is no requirement that the generator of these responses
(when presented with a request/need to sent such a message to more
than one recipient) create a single copy of the message as opposed to
one personally addressed copy per recipient. Creating multiple copies
preserves the "Only One Recipient for a 'Mail From <>' message" rule.

what rule is that?  please cite the standard.

Keith,

I don't think there is implicitly stated rule in the RFCs.  A quick review
of RCPT TO related material does not indicate a limit for NULL return paths.

However, it is an administrative option and it exist because the need was
apparent and they asked for it.  So implementations programmed the
administrator local policy option or they began to use what was already
possible for them.

What I am pointing out that that it is being enforce more and more, and the
main reason is because it was being exploited by spammers.

I see two critical points.

First,  if there are conflicts, the limit itself should not be the reason,
but rather the false assumption by an agent that tries to use this to
BROADCAST, not BOUNCE, electronic mail using a NULL return path.

Second,  it isn't an issue unless there is a post-smtp recipient validation
concept that triggers the non-deliverable accepted message bounce
requirement.

For example:

For a dynamic SMTP RCPT checker:

    MAIL FROM: <>
    RCPT TO:  <good user1>
    250 ok
    RCPT TO:  <good user2>
    250 ok
    RCPT TO:  <bad user3>
    451 doesn't exist
    RCPT TO:  <good user4>
    250 ok
    RCPT TO:  <bad user5>
    451 doesn't exist

In a transaction like this,  a non-restrictive system will accept the 3 good
systems.  Some systems will actually count the errors and may abort the
transactions or stop accepted more RCPT TO commands.    Some have limits
altogether.

But what is important here, there is no bouncing, even of the MAIL FROM: was
not NULL.  This is an instant notification concept.

For the post SMTP system

    MAIL FROM: <>
    RCPT TO:  <good user1>
    250 ok
    RCPT TO:  <good user2>
    250 ok
    RCPT TO:  <bad user3>
    250 ok
    RCPT TO:  <good user4>
    250 ok
    RCPT TO:  <bad user5>
    250 ok

We now have 2 bad address and under normal circumstances it will a bounce
consideration.    But there is none due to the NULL return path.

These are the type of abuses you will see from SPAMMERS, not the SORBIG
based bounce-based attackers.

For the SPAMMER, they will use a NULL, POSTMASTER or a BAD or SPOOFED
address..

For the SORBIG-based generation eViruses,  they will not use a NULL return
path, but typically a spoofed address, not bad.

They seek post smtp validation systems, because this gives them a dual tier
distribution:

   - 3 messages, for 3 potential good addresses reaching 3 local users

   - 2 bounces to 1 potentially good sender return path address.

So whether there is or not a "rule" regarding NULL return path RCPT limits,
the reality is what it is and people are addressing this and in my opinion,
it fits the framework better than allowing a open ended NULL broadcasting
concept.   As you said, not every system supports your optional DSN
specification, but even then, the NOTIFY=NEVER modifier will be scrutinized
as a potential exploit.   The SPAMMER may use it.  The SORBIG attacker will
not.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com



<Prev in Thread] Current Thread [Next in Thread>