Bounce or Discard?
There are two common way to process unaccepted letters: One is bounce, a.k.a. give the sender a message saying “Your letter is bounced.” Another is discard, in other words, drop the letter silently.
Today Prof. Jiang (my mentor) received a bounced letter saying that he is sending virus mail. The letter supposed that he has sent virus through the mail server in Beijing University of Technology, and this is nearly impossible because the mail server at BJUT is under protection behind a well-maintained anti virus mail gateway, hence all viruses will be filtered out.
On the other hand, however, it will be a small maintaince problem when e-mail does not get bounced. For instance, if the server silently discard a letter user sent out, then he or she will simply lose their credit because non-responsiveness.
A possible workaround of this problem is to enable DSN on mail servers. For instance, when the mail storage actually received the mail, it returns a recipent. However, this can be easily exploited if your server has some (silly) quota based limits. A workaround of that problem over this workaround will be, when DSN is received without prior sent stub saved, we simply discard it.
The two workarounds are “workaround"s. The first alone is bogous, and the latter is complex, and we all know if a solution is too complex, it must be incorrect.
A possible solution of the problem should be have all servers running a PKI based authentication mechanism. When sending mail under a domain name, the mail server must provide proper signed message to verify that the letter is actually sent under the name. This, in turn, brought some major benefits:
It will be easy to block non-responsive servers. A independent organization can provide a X.509 certificate authority and revoke certificates when the servers are doing non-responsiveness things.
The integrity could be better guaranteed as the security algorithms applied can easily do this, rather than guaranteeing these under a TCP error control mechanism.
Encryption can be applied in addition of the S/MIME cryptology mechanisms, hence guarantee more of identification proofs.
To make the new RFC proposal enforced, there must exist several new protocal extends over the current SMTP protocol. For instance:
Older client/server is allowed to connect the new server, and a warning will be returned so the user is encouraged to use a newer client/server.
When connecting a server that does not talk new protocol, the server is allowed to add some warning messages inside the message.
This will allow new server to have a smooth upgrade migration process, while retaining the possiblity to compatible with existing installations.