ietf-asrg
[Top] [All Lists]

Re: [Asrg] Ban the bounce; improved challenge-response systems

2003-04-07 13:12:31


On Mon, 7 Apr 2003, J C Lawrence wrote:

On Mon, 7 Apr 2003 07:00:17 -0400 (EDT) 
Daniel Feenberg <feenberg(_at_)nber(_dot_)org> wrote:
On 6 Apr 2003, wayne wrote:

Could the receiving MTA, when it must send a DSN, restrict itself to
connecting to the connecting MTA or one of its MXs? In that case a
forged envelope from would typically result in a "relay denied" rather
than sending the DSN to an innocent third party. If the envelope from
was in a domain that the connecting MX serviced, presumably it would
accept and deliver the DSN. If the spammer forged addresses in the
scope of the connecting MTA, the DSN would still go through, of
course, but the burden would be on the "legitimate" users of the MTA,
which would encourage relays to be closed and spammer's accounts to be
canceled.

While not making it impossible, this gets interesting when a message
transits a secondary MX.  Something has to track the originating
domain/MX for the transaction -- which in turn either exposes that
tracking to spammer forgery, or suggests that a new/different/custom
transport protocol be used between MX levels which is different than is
used for base message transfer.


Two of the objections raised in the last several messages are not
convincing. A third is more interesting.

(1) If you have some relationship with the secondary MX, and I assume you
have, you can easily tell that the Received header from it was not forged.
Therefore the IP address of the connecting host of the stranger machine
is available in the headers with some high level of confidence. The bounce
message can then be sent to that machine, or an MX for that machine
discovered through RDNS. 

(2) In answer to a previous message, RDNS always provides a host name or
an error, never a network number or subnet range.

(3) With respect to aliases, if you can't pass the message on to another
host, you can send a DSN to your connecting host with confidence that it
is the the immediate source of the message. The problem arises if the
final destination wants to reject the message. Then they have to send it
to a strange MTA that they have had no prior contact with. If they send to
the connecting machine, that machine will (unless it is an open relay)
reject the message with "We do not relay". That leaves the destination
with a choice of sending to the sender address or dropping it on the
floor. I assume most sites would chose to send to the possibly forged
address, but it might depend upon the reseason for refusing the message.
If it was because the content was spammy, it might make more sense to drop
the message on the floor. 

After all, the rationale for rejecting messages is to avoid the situation
where one has accepted a message, found it to be spam with 99%
probability, but don't want to drop it on the floor because of that final
1%. Nor do you want to issue a DSN that will go to a forged address with
75% probability. Supplying a DSN only if the sender is reachable via the
connecting machine or an MX for it seems like a reasonable compromise.




_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg



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