On 6 Apr 2003, wayne wrote:
In <20030406042307(_dot_)GC994(_at_)m1800> waltdnes(_at_)waltdnes(_dot_)org
writes:
The receiving MTA should always try hard to make the sending MTA
generate the bounce via the 5xx reject codes. It should also try to
verify that the MAIL FROM address is valid before it accepts the email
so that if a bounce has to be generated later, it can be. Exim can
verify not only the MAIL FROM, but also the From:, Reply-To: and
Sender: headers to try and cut down on bad bounces.
Something like the RMX or domain-specific DNSBL solution would also
help make sure that later bounces are not being sent to third party
spammer victims.
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.
Regards,
Damon
*****
"The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential, proprietary, and/or
privileged material. Any review, retransmission, dissemination or other use
of, or taking of any action in reliance upon, this information by persons or
entities other than the intended recipient is prohibited. If you received
this in error, please contact the sender and delete the material from all
computers."
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg