Should "trusted" hosts be reported

[nogin]

Should "trusted" hosts be reported and still count against the BL?

In the new mailhost system, if the relay IP is considered trusted, then the IP is not reported and the spam report is not counted towards BL listing for that IP. Im my opinion this is putting too much trust in these "trusted" hosts. Please consider splitting the "trusted" flag into three separate ones:

• "The host is trusted to record the originating IP correctly". When the flag is set, then consider the "received from" IP in the "Received" line reported by the host for reporting in addition to the host's own IP.
  
• "The host is trusted to filter its own incoming truffic via the SpamCop BL". When the flag is set, it is safe not to count the spam towards the BL listing. Without such flag, the stats should be recorded - if the host relays too much spam to other ISPs, it deserves to be listed in BL.
  
• "The host should not get reports for spam it relays". Unless this flag is set, the IP owners should get reports for the spam they relayed to other ISPs (possibly leading to more than one IP reported per spam, which is IMHO OK). Unless they explicitly request it, this flag should never be set for mail servers that authenticate their clients (such as webmail servers) as they could have enough information to shut down the spammer themselves.
  

[A.J.Mechelynck]

Should "trusted" hosts be reported and still count against the BL?

In the new mailhost system, if the relay IP is considered trusted, then the IP is not reported and the spam report is not counted towards BL listing for that IP. Im my opinion this is putting too much trust in these "trusted" hosts. Please consider splitting the "trusted" flag into three separate ones:

•    
  
• "The host is trusted to record the originating IP correctly". When the flag is set, then consider the "received from" IP in the "Received" line reported by the host for reporting in addition to the host's own IP.
     
  
• "The host is trusted to filter its own incoming truffic via the SpamCop BL". When the flag is set, it is safe not to count the spam towards the BL listing. Without such flag, the stats should be recorded - if the host relays too much spam to other ISPs, it deserves to be listed in BL.
     
  
• "The host should not get reports for spam it relays". Unless this flag is set, the IP owners should get reports for the spam they relayed to other ISPs (possibly leading to more than one IP reported per spam, which is IMHO OK). Unless they explicitly request it, this flag should never be set for mail servers that authenticate their clients (such as webmail servers) as they could have enough information to shut down the spammer themselves.
  

I don't agree, and here is why:

My own ISP has an optional spam-filtering option, which, if set, removes any email "detected as spam" before the user sees it. Since I am one of those who prefer a few false negatives to even a single false positive, I have intentionally turned that option off on my accounts, and I do my own filtering on incoming mail, using the SCBL and several others, and diverting rather than refusing. Some emails (e.g. those addressed "To" a ML to which I am subscribed) are re-directed away from the "spam" folder by a mail-client "rule" whether or not my spam filter has marked them as "probable spam". Thus, on the mail I get, my ISP does (if it obeys my settings) no spam filtering whatsoever; nevertheless, I don't want to see it listed for having relayed spam to me. I prefer to get all my mail, sort it myself into legit (unlisted), spam (listed), spam (not yet listed = false negative) and legit (but listed = false positive), so I can (-a-) get my legit mail even if listed, and (-b-) report false negatives immediately (by web) to put them on the list, and also the listed spam if and when I have time (by mail) to keep it on the list.

[...]

But that isn't the point of this message... I want to make a suggestion...

On the 'technical details' page, next to the bit where it says "untrusted relay - not trusting anything beyond this point" (or words to that effect), why not simply place a hyperlink that says "actually, I DO trust this relay".

Then, we can click on that link and add the host that way.

Or is this just not feasible for technical reasons beyond my humble comprehension?

Hm... It does have pros and cons (the "cons" being related to the possibility that clueless users might click it indiscriminately and add to their mailhost list a number of hosts which don't belong there.)

Last week I had a similar suggestion, but I made it by private mail to Ellen & Julian. The idea was similar, but with a slight variation.

I suggested that, in the cases when the parser now says "You haven't completed your configuration", a set of radio buttons be added after the jump-to point of the "Skip to reports" link, maybe something like this:

"blah-blah-blah.hotmail.com" is trusted but not configured.

Does it belong to your own ISP ?

( ) Yes ( ) No (x) Don't know

• "Yes" would add it to the user's mailhosts immediately.
  
• "No" would accept the recived-line (as it does now), not add the unconfigured trusted host to the user's mailhosts, and avoid the scolding line "You haven't completed your configuration"
  
• "Don't know" would produce a message at the top of the "Reports sent" page, with a wording maybe "softer" than it is now, let's say:
  Your mailhosts configuration seems incomplete. Please reconfigure.
  i.e. with a link to the mailhost configuration page.
  

This would make it easier for users with complex configurations, but of course it is not immune to clueless users clicking "Yes" indiscriminately. I hoped that a clueless user would leave it at "Don't know" but my hopes are not necessarily well-founded in that matter.

Of course Julian will have the final say.

[nogin]

Should "trusted" hosts be reported and still count against the BL?

In the new mailhost system, if the relay IP is considered trusted, then the IP is not reported and the spam report is not counted towards BL listing for that IP. Im my opinion this is putting too much trust in these "trusted" hosts. Please consider splitting the "trusted" flag into three separate ones:

•    
  
• "The host is trusted to record the originating IP correctly". When the flag is set, then consider the "received from" IP in the "Received" line reported by the host for reporting in addition to the host's own IP.
     
  
• "The host is trusted to filter its own incoming truffic via the SpamCop BL". When the flag is set, it is safe not to count the spam towards the BL listing. Without such flag, the stats should be recorded - if the host relays too much spam to other ISPs, it deserves to be listed in BL.
     
  
• "The host should not get reports for spam it relays". Unless this flag is set, the IP owners should get reports for the spam they relayed to other ISPs (possibly leading to more than one IP reported per spam, which is IMHO OK). Unless they explicitly request it, this flag should never be set for mail servers that authenticate their clients (such as webmail servers) as they could have enough information to shut down the spammer themselves.
  

I don't agree, and here is why:

My own ISP has an optional spam-filtering option, which, if set, removes any email "detected as spam" before the user sees it. Since I am one of those who prefer a few false negatives to even a single false positive, I have intentionally turned that option off on my accounts, and I do my own filtering on incoming mail, using the SCBL and several others, and diverting rather than refusing. Some emails (e.g. those addressed "To" a ML to which I am subscribed) are re-directed away from the "spam" folder by a mail-client "rule" whether or not my spam filter has marked them as "probable spam". Thus, on the mail I get, my ISP does (if it obeys my settings) no spam filtering whatsoever; nevertheless, I don't want to see it listed for having relayed spam to me.

I am sorry, but you seem to have completely missed the point of my post. I am specifically talking about the case where another ISP has a mail server that is marked "trusted" by deputies. Of course, my proposal has nothing to do with the "this is my own mailserver[\I]" flag set by the basic Mailhost system.

[turetzsr]

Should "trusted" hosts be reported and still count against the BL?

In the new mailhost system, if the relay IP is considered trusted, then the IP is not reported and the spam report is not counted towards BL listing for that IP. Im my opinion this is putting too much trust in these "trusted" hosts. Please consider splitting the "trusted" flag into three separate ones:

   

• "The host is trusted to record the originating IP correctly". When the flag is set, then consider the "received from" IP in the "Received" line reported by the host for reporting in addition to the host's own IP.
     
  
• "The host is trusted to filter its own incoming truffic via the SpamCop BL". When the flag is set, it is safe not to count the spam towards the BL listing. Without such flag, the stats should be recorded - if the host relays too much spam to other ISPs, it deserves to be listed in BL.
     
  
• "The host should not get reports for spam it relays". Unless this flag is set, the IP owners should get reports for the spam they relayed to other ISPs (possibly leading to more than one IP reported per spam, which is IMHO OK). Unless they explicitly request it, this flag should never be set for mail servers that authenticate their clients (such as webmail servers) as they could have enough information to shut down the spammer themselves.
  

I don't agree, and here is why:

My own ISP has an optional spam-filtering option, which, if set, removes any email "detected as spam" before the user sees it. Since I am one of those who prefer a few false negatives to even a single false positive, I have intentionally turned that option off on my accounts, and I do my own filtering on incoming mail, using the SCBL and several others, and diverting rather than refusing. Some emails (e.g. those addressed "To" a ML to which I am subscribed) are re-directed away from the "spam" folder by a mail-client "rule" whether or not my spam filter has marked them as "probable spam". Thus, on the mail I get, my ISP does (if it obeys my settings) no spam filtering whatsoever; nevertheless, I don't want to see it listed for having relayed spam to me. I prefer to get all my mail, sort it myself into legit (unlisted), spam (listed), spam (not yet listed = false negative) and legit (but listed = false positive), so I can (-a-) get my legit mail even if listed, and (-b-) report false negatives immediately (by web) to put them on the list, and also the listed spam if and when I have time (by mail) to keep it on the list.

<snip>

...Did you forget to include the part that explains why you disagree?

...IIUC, implementing nogin's suggestion should affect you not at all. Your explanation involves whether or not you actually see what your ISP would consider incoming spam, whereas nogin's suggestion has only to do with whether an IP address should be considered as a possible spam source when reporting spam. Or have I missed something?

[A.J.Mechelynck]

[...]

...Did you forget to include the part that explains why you disagree?

...IIUC, implementing nogin's suggestion should affect you not at all. Your explanation involves whether or not you actually see what your ISP would consider incoming spam, whereas nogin's suggestion has only to do with whether an IP address should be considered as a possible spam source when reporting spam. Or have I missed something?

The way I understand it, nogin's proposal #2 is to flag hosts according to whether ot not they reject SCBL-listed spam attempting to go through their servers, and if they don't, to count the spam that goes through their servers as though it had come from said servers. So, (again, IIUC) if that proposal were put into practice, then either:

1. if I changed nothing, then the 100 to 200 daily spam I get via my own ISP's servers would contribute towards moving them onto the SCBL, thus potentially compromising those of my fellow [at]skynet.be users who do use the spam-filtering option (assuming that the SCBL is one of the DNSBLs used by my ISP's spam filter), or else jeopardising the utility of the SCBL itself, or of the option not to use it, for my ISP (and any ISP with similar policies); or
   
2. if, in order to avoid such listing, I set the "spam protection" option (or if, $DEITY forbid, my ISP changed policies and decided to set it mandatorily for everyone), and if I somehow found a way to set the SC "I reject based on SCBL" flag on my ISP's incoming-mail servers, then I would cease receiving any mail from SCBL-listed sources, even if the particular email in question were actually legit (false positive). And I wouldn't even know that a rejection had taken place.
   

[A.J.Mechelynck]

[...]

I am sorry, but you seem to have completely missed the point of my post. I am specifically talking about the case where another ISP has a mail server that is marked "trusted" by deputies. Of course, my proposal has nothing to do with the "this is my own mailserver[\I]" flag set by the basic Mailhost system.

Me too, I was talking of the case when the spam comes to the Mailhosts from some other, unrelated, mail router already marked "trusted" by deputies (but that was in the part you snipped). I got that case twice (both times coming from hotmail) and both times I got a message in red saying that I hadn't completed my configuratiuon and that I must configure all of my mailhosts. Of course, no matter how many times I repeat the configuration process, the SC configuration emails won't reach my .isp.belgacom.be servers (for [at]skynet.be and [at]belgacom.net) by way of Hotmail, so I have no way of removing that "unfriendly" red line in the rare case (twice since this past Wednesday, among something linke 150 spam /24h) when the spammer uses neither direct-to-MX nor open-proxy routing, but goes through a bona-fide outgoing-email server (probably for a throwaway account).

Both times that Hotmail received-line was the bottommost (earliest) one, so both times the SC report went to the ISP responsible for whoever injected the mail (even though it didn't go through that ISP's mail servers), giving them a chance to hit the spammer where it hurts, by (hopefully) having his modem go dead...

Of course, when Belgacom next puts new mail routers into service, I may get that message again, this time about something about which I will be able to do something. But even though I don't expect that before a year or two from now, it would be simpler to add such new mail routers to the mailhosts lists from the parse page than by going through the present configuration rigmarole, especially if those new routers were to be used "in transit" for some mails and not for others. But there are arguments against it too.

I thought you were talking about "all" trusted mail routers, whether they were trusted by being explicitly in the mailhosts list, or implicitly by having their domains in the mailhosts list, or by having a global "trusted" flag set by deputies.

Aside from the "You must complete your configuration" message mentioned above, I also get relatively often the message "Forgery detected or configuration incomplete. Please verify the source IP detected" (or words to that effect) fut AFAICT it was always about a bogus received-line (a few minutes ago, for a message injected at .verizon.net, trying to pass that verizon router as belonging to .yahoo.com).

[nogin]

Replying to my own post:

Should "trusted" hosts be reported and still count against the BL?

I see that this suggestion is already implemented and "webmail"-like "trusted" relays are being listed as report recepients. Thanks a lot for such a quick reaction!

[Michael A Chase]

If I understand the mailhosts initiative, it causes parsing to stop after the last known mail host. This means that any spam sent through a mail list will be attributed to the list server.

Is there any way to register mail list hosts so the real source of the spam can be reported?

[StevenUnderwood]

There seem to be more "trusted" hosts. I am not sure of the method to get that accomplished, but if a list is not controlling it's spammers, I'm not sure if they shouldn't be listed.