On Mon, 7 Apr 2003, Sauer, Damon wrote:
On 6 Apr 2003, wayne wrote:
In <20030406042307(_dot_)GC994(_at_)m1800>
waltdnes(_at_)waltdnes(_dot_)org writes:
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.
If I understand what you are saying correctly, you are saying that a DSN
should be returned to the sending IP. (I am not sure how you would be able
to parse correctly the MX from the reporting IP or hostname of the
connecting server.)
While I agree with what you are saying on merit, this would unfortunately
break many large SMTP implementations. Many mailers are "outgoing" only and
buried deep inside an intranet. Saying that all MTAs MUST be able to receive
DSN's would be restrictive to current SMTP implementations and require
substantial changes in SMTP routing design of many current networks.
The MTA wishing to send a DSN would do a reverse dns lookup on the
connecting MTA, then find the appropriate MX record, or use the A record
if none were found.
I understand that many large sites are too busy to support RDNS, or to add
an MX record for their MTAs, in which case they might miss some DSN
traffic. It would be up to them. At some future date, they could hire
additional engineers to handle the project.
Seriously, I realize that half of sites don't have RDNS, but the A record
will accept mail for nearly all of those sites. And it is no tragedy if it
doesn't, it is their choice and must be respected.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg