Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About WMTyson

  • Rank
  1. In a SpamCop mail page, there is a section A person who got a bounce message for a forged message allegedly from him to our site reported that bounce message. (The mail was to a mailing list where the software rejected his mail because he was not a member. Unfortunately the mailing list's bounce message was not according to RFC1894, but is obviously a bounce message.) I'm not interested in getting this person in trouble (I can imagine their confusion), but I do want to clear this report. The page linked to by the report gives two buttons spam will cease Append note only In our case, there was no spam. The sysadmin that responded to this report has declined to push this button because there was no spam and no action was taken. If it is correct to click on "spam will cease", I would urge a more clear statement that indicates this button is to be used if the report was in error. Elsewhere ( http://news.spamcop.net/cgi-bin/fom?file=146 ) I found a distinction between resolved and innocent. I don't want to say "resolved" if "innocent" is the correct response. Is it correct to use that button, or is there a different way to resolve this? The ID on the incident is 658728925 Thanks....
  2. I disagree with much that has been said. I am concerned that a number of people in this thread have seemingly ignored the fact that Spamcops rules indicate that the user should not submit spamcop messages for "bounces generated because of spam forged in your name". They seem to feel that such bounces are spam. ("[They will never] get a real grasp on the problem they are causing.") 1. A virus notification is a form of an "Undeliverable Mail" DSN (Delivery Status Notification) message, not spam. Bounce messages are valid mail, and even required by the RFCs. RFC 2821 (http://www.faqs.org/rfcs/rfc2821.html) where 24 = RFC1891 and 25 = RFC1894 Even though the RFCs require it, I would think it prudent to avoid generating a DSN when the system can detect that the mail was forged (in particular when the content matches a known forging worm's signature). However, anyone's assertion that such a DSN message is spam seems to ignore the standards required of the Internet. 2. Re the claim that anti-virus systems "spam" because they identify themselves. a ) The one we use, Symantec's NAVSMTP, as we have it configured, does not identify itself (which I think is wrong, but then I don't control it). b ) RFC 2821 addresses the issue of (mail) systems identifying themselves (as a security issue, not as an advertising issue). As I read it, the RFC indicates that making this system available allows debugging which, in their opinion, outweighed the argument for security-through-obscurity. I feel the same way about anti-virus s/w. I also feel it is appropriate for me to see who is using what so I can better evaluate what AV s/w might be best. c ) Of course it is wrong if the AV s/w does more than identify itself, what it found, what site applied it, and maybe a contact address. But those basics do not constitute spam any more than an User-Agent heading in the header of a message. 3. In our case, someone (IMHO, erroneously and in violation of http://news.spamcop.net/cgi-bin/fom?file=14) reported our site to Spamcop in response to the following situation. This is NOT a case of a virus notification message, but is a person reporting a "bounce" message that was a result of forged worm mail. But it illustrates some of the intricacies of mail delivery & bounce messages. Worm at forges mail from nobody[at]example.com (with legitimate names, of course) and sends it to mailing-list[at]oursite. The MX for oursite disables (replaces with a message) the worm code in the message and continues the delivery (This modification is technically in violation of RFC2821 2.3.8 but seems to be a valid attempt to deliver the message. Please remember that not all viruses are mass-mailing & forging.) The mail is relayed to the host that is responsible for handling the local part "mailing-list". At this point, it is technically out of the SMTP protocol and is just mail that is to be delivered "locally". The mailing list software then gets the submitted mail. Because the mail does not meet the standard for the mailing list (in this case, because the (alleged) sender is not authorized to submit to the list), the mail is not sent to the list. At this point, the mailing list software (in our case, Listar) generates a "bounce" message to the sender. There is NO way that this software might reasonable infer that the sender was forged or that the mail ever contained a worm. Nor should it. "Bounce" is in quotations because the message is not in a format specified by RFC 1894. In my opinion, this is a bug (even though I believe the software predates that RFC). However, to a human, the mail is clearly seen as a "Your message was rejected because ..." message. The innocent person, whose address was forged, received this "bounce" message and reported it as spam. I am sympathetic that the person may be clueless about what happened but they can clearly see that the message is a bounce message and contains no self-promoting message of any sort and therefore should not have reported it to Spamcop. (Obviously I don't know the individual who reported the "spam" but I wonder if this was an (semi-)automated report. An auto-responder reporting a different auto-responder.) I understand that Spamcop can not automatically detect our bounce message as being a bounce message. I don't know, but I hope that Spamcop will detect many DSN messages (as formatted according to RFC1891 and RFC1894) and ignore those reports. It is our intent to find a better mailing list processing software but it will not happen soon. I now better understand the need for it to generate properly formatted bounce messages. 4. Regarding the issue of using SMTP codes to reject mail. This is an unnecessary sidebar to the discussion and only clouds the issue. All the error code does is to change who generates a bounce message. Suppose spammer inserts mail on host Source-Host to be delivered for Dest-Host with a forged address of nobody[at]example.com. In order for the MTA at Dest-Host to reject the mail via SMTP because it has a virus, it has to run the mail through a virus scanner of some sort. All that time, it must keep open the SMTP connection from Source-Host. The problem gets even worse if you think of the MTA also checking for spam which might include offsite queries to check to see if the mail body has been reported as spam. So, after some possibly non-trivial amount of time, if it decides it doesn't want the message, it reports a 550 SMTP error message (which is pretty non-specific!). All that time, Source-Host and Dest-Host were keeping open the SMTP connection. Granted that's not too much overhead, but I think most mail systems balance the number of SMTP connections with the amount of effort to send/receive mail in order to not overload their system. Changing the nature of whether the connections are actively transmitting mail or just sitting around waiting for s/w to run will upset that balance. What should have been maybe a <0.1 second transmission might become a 5 or 10 second transmission time. Ok, suppose finally that Dest-Host rejects the mail. Now, it is Source-Hosts's responsibility to report that non-delivery to the (alleged) sender. The poor innocent gets the bounce message from Source-Host. Suppose Dest-Host simply accepted the mail and then later decided it was spam and decides not to deliver it to "nobody". In this case the poor innocent gets the bounce message from Dest-Host. Not much difference. The only difference I see is that Source-Host might get overwhelmed delivering the bounce messages as well as spam, if a lot of spam was being sent from Source-Host. But that difference is gone if the destination host has an MX host that accepts the mail first with a subsequent relay to the destination host (Dest-Host) where the virus/spam checking is done. (Our site actually has separate MTAs that do spam and virus checking. One of them won't be first in line!)