Talk:Backscatter (email)/Archives/2015
 | This is an archive of past discussions about Backscatter (email). Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Definition of Drop
The definition of drop in this article includes messages that are delivered to a users Spam or Junk folder. These are not dropped messages because they have been delivered appropriately, it's up to the user whether he wants to check his Spam folder or not but the message is there for him to check for regardless.
Dropped messages are those that are first accepted (with a 2xx status code) and then silently discarded by the system so that there is no trace to the user that they were ever sent at all. The sender is left with the false impression that the message was delivered to the recipient which was not the case.
Note that the referenced RFC 5321 does not give a definition of the term "drop" as it relates to email. I am hard-pressed to find an RFC that does.
Pajamian (talk) 03:33, 14 April 2013 (UTC)
> Fixed. Also updated the main article about how this "backscatter" config can happen today. Normally, its no longer "naïve sysadmins" that configure their systems to backscatter, rather its today, more common that the mail are sent to a heavy processing step, that cannot be used while the SMTP client sits and waits for a reply from the SMTP server, because then it would reach the timeout value and the client would disconnect telling the user that the server didn't reply. In those cases, most mailservers are, out of the box (default config) today configured to automatically reply with a bounce message, but this can be easily be turned off in configuration, causing the mailserver to silently drop such emails instead.