Kevin,
On 26/03/15 11:18, Kevin A. McGrail wrote:
On 3/26/2015 7:09 AM, Reindl Harald wrote:
why in the world would a reject *before queue* trigger a backscatter
or bounce on my side?
To me, your recommend action makes you only worried about your tiny star
in the universe of mail servers and ignores the community responsibility
you have as an IT administrator. *Your* actions are contributing to
backscatter and you have a *choice* to handle it differently *without
malicious intent* to make the computing world a better place. I don't
care if your server does or doesn't end up actually sending the DSN.
For example, in the scenario where server A sends a virus to your server
B, my opinion is that I have a duty to act to protect the public at
large and go "this is a virus, send a dsn 200 and silently discard".
In any case, it does not appear you are going to change my opinion so
stop beating a dead horse, agree to disagree and let's move on.
Whilst I don't agree with Harald about the complete ban on silent
discards; there is a time and place for any and all means at our
disposal as e-mail administrators provided some common sense is applied,
however I really don't agree with your viewpoint about rejections here:
> For example, in the scenario where server A sends a virus to your server
> B, my opinion is that I have a duty to act to protect the public at
> large and go "this is a virus, send a dsn 200 and silently discard".
In this case if server B rejects the message outright, then it is server
A's responsibility to create a DSN/MDN and that absolutely doesn't make
server B at fault at all, there is no 'community responsibility' to
discard it whatsoever.
The biggest common cause for backscatter is all of the e-mail admins
that have systems that don't reject invalid recipients at SMTP time but
instead accept all recipients and then cause the MTA to bounce the
message back to the return-path when the delivery fails. It's these
folks and their vendors that have a community responsibility to clean up
their act.
Kind regards,
Steve.
