Jump to content

Error in recipient address


Recommended Posts

... And who sends the deputies a link to a forum topic?
I have, in the context of "such and such is seen", being some sort of description/summary of the problem and "see [link] for more detail" OWTTE, a shorthand way to cover all of the content placed on the table. But never "just a link", I'm sure. But, in retrospect, it would have been helpful, as requested, to pull any tracking urls from the forum discussion and include them right there in the email. Not that I send many. "We" try to keep the workload off them, not add to it.

I guess I just assumed any action by staff would involve prudent review of the precursory materials (anamnesis) once the problem was nominated. And I have advised others they could point to the forum topic when contacting deputies as a way to avoid a lengthy email, particularly (but not exclusively) if they seemed to struggle a little in initially expressing/defining the matter. Same logic.

Well, Don has provided a preferred template but I would still recommend, in addition, including a link to the forum topic in most cases as a matter of prudence so Don/the deputies don't get blindsided/waste time through any omissions in the email description. To turn around Don's phrase (re the skills of himself & deputies), a supplicant's knowledge/skills do not approach those of the paid staff concerning these problems and (logically) they cannot be expected to always mention all matters of significance - or necessarily to even use 'proper' terminology. If Don and (him speaking for them) the deputies have no confidence in the forums to assist in that regard, that is of course their call - but he has not actually said that.

Bottom line, as a minimum, we must all be sure the email nominates the specific problem in the title, gives concise detail in the body and includes an illustrative tracking URL where appropriate, which will be most times.

Link to comment
Share on other sites

  • Replies 53
  • Created
  • Last Reply

Not to change the subject, but I see the same reporting address errors still exist.

http://www.spamcop.net/sc?id=z1886567770z4...c4a69b58a3ab52z

.sk error.

-----

http://www.spamcop.net/sc?id=z1886678724z1...54f398f040b8ffz

Resolves to 85.13.132.92

Routing details for 85.13.132.92

[refresh/show] Cached whois for 85.13.132.92 : ip[at]all

Using last resort contacts ip[at]all

ip[at]all bounces (7 sent : 7 bounces)

I should be ip[at]all-inkl.com

Link to comment
Share on other sites

Not to change the subject, but I see the same reporting address errors still exist.

sk error.

-----

I should be ip[at]all-inkl.com

Argh! More hyphenated address errors.

I fixed the top one but couldn't fix the bottom one, so I turned them over to Ellen, who is our routing guru.

- Don D'Minion - SpamCop Admin -

Link to comment
Share on other sites

Not to change the subject, but I see the same reporting address errors still exist.

http://www.spamcop.net/sc?id=z1886567770z4...c4a69b58a3ab52z

.sk error.

this one seems to have been fixed
http://www.spamcop.net/sc?id=z1886678724z1...54f398f040b8ffz

Resolves to 85.13.132.92

Routing details for 85.13.132.92

[refresh/show] Cached whois for 85.13.132.92 : ip[at]all

Using last resort contacts ip[at]all

ip[at]all bounces (7 sent : 7 bounces)

I should be ip[at]all-inkl.com

sent email to deputies on this one

edit: this one also seems to have been "fixed" but - reports to the reporting address have been disabled

Cached whois for 85.13.132.92 : ip[at]all

Reports disabled for ip[at]all-inkl.com

Using best contacts

No reporting addresses found for 85.13.132.92, using devnull for tracking.

edit: this was started prior to Don post that proceeds it but posted after it.

Link to comment
Share on other sites

The main problem apprears to be the fact that the WhoIs lookup is broken. Any domain name that contains a hyphen get truncated at the hyphen. It appears that deputies are fixing each domain individually to obtain a correct reorting address, while the Whois information continues to be wrong.

Hopefully the Whois function can be fix which should then fix the problem for all domains rather than having to deal with each domain individually

Link to comment
Share on other sites

So here's something I've wondered about these reporting addresses.... why does SpamCop not use the cached WHOIS information in some instances and instead use the postmaster address?

Example: http://www.spamcop.net/sc?id=z1886567134za...a738152ece2d5dz

I don't see notes that show attempts to send to the cached addresses are turned off or bounced, so doesn't sending to the 'postmaster' address actually reduce the effectivness of the report system?

Link to comment
Share on other sites

FYI, this one is still not resolving correctly:

http://www.spamcop.net/sc?id=z1886995648z6...74e0064216c708z

Resolves to 195.137.213.130

Routing details for 195.137.213.130

[refresh/show] Cached whois for 195.137.213.130 : abuse[at]server

Using abuse net on abuse[at]server

Using best contacts abuse[at]server

abuse[at]server bounces (13 sent : 7 bounces)

Should be abuse[at]server-home.net

Link to comment
Share on other sites

Routing details for 195.137.213.130

[refresh/show] Cached whois for 195.137.213.130 : abuse[at]server

Using abuse net on abuse[at]server

Using best contacts abuse[at]server

abuse[at]server bounces (13 sent : 7 bounces)

It seems strange that the system would even attempt to send email to a total bogus address.
Link to comment
Share on other sites

It seems strange that the system would even attempt to send email to a total bogus address.

This was also noted in my "follow-up" e-mail. As you note, the abuse[at]server bounces (13 sent : 7 bounces) seems very suspect.

Again, this is obviously a coding issue that needs the programming staff to get involved, which is what my "follow-up" e-mail stated. You know, after all this discussion and the repeated references, I am finally willing to agree with Don's word of ignored.

Link to comment
Share on other sites

...Again, this is obviously a coding issue that needs the programming staff to get involved, which is what my "follow-up" e-mail stated. You know, after all this discussion and the repeated references, I am finally willing to agree with Don's word of ignored.
Trouble is, both Don and Ellen have said before, IIRC, they hold no sway with Engineering. Which has to be at least as frustrating for them as it is for the users affected. Defective (non)cycle IMO (no closed system remains in control without modifying feedback). We can only wonder about priorities ... well, it's evidently not a closed cycle. There's those pesky spammers constantly permeating the membrane, for a start.
Link to comment
Share on other sites

  • 3 weeks later...

For the information of SC admins, see tracking link.

SC seems to get an incomplete reporting address ("abuse[at]btc") out of the WHOIS data for the IP address in question. I think this may have happened some time back, perhaps to the same contact.

-- rick

Moderator Edit: merged this new Topic into the existing Discussion about the same subject. PM sent to advise of the movement.

Link to comment
Share on other sites

For the information of SC admins, see tracking link.

SC seems to get an incomplete reporting address ("abuse[at]btc") out of the WHOIS data for the IP address in question. I think this may have happened some time back, perhaps to the same contact.

Yep, obviously the Ticket that Ellen submitted has yet to closed. In this case, the problem is shown at;

Tracking details

Display data:

"whois 79.100.44.177[at]whois.arin.net" (Getting contact from whois.arin.net )

Redirect to ripe

Display data:

"whois 79.100.44.177[at]whois.ripe.net" (Getting contact from whois.ripe.net)

Abuse address in 'remarks' field: abuse[at]btc-net.bg

whois.ripe.net found abuse contacts for 79.100.44.177 = abuse[at]btc

whois: 79.100.0.0 - 79.100.255.255 = abuse[at]btc

Routing details for 79.100.44.177

Using abuse net on abuse[at]btc

Using best contacts abuse[at]btc

Another hyphenated Domain name that gets broken by the parser's "tageting" routine.

Link to comment
Share on other sites

Another hypenated Domain name that gets broken by the parser's "tageting" routine.
Thanks for the archaeology, Wazoo. Yes, this is the thread I recalled. And, yes, the problem appears to be the same (pesky hyphens).

-- rick

Link to comment
Share on other sites

Thanks for the archaeology, Wazoo. Yes, this is the thread I recalled. And, yes, the problem appears to be the same (pesky hyphens).

I'm going ight now with that Don said he monitors this Forum section, did in fact apply at least one fix in the previous part of the Discussion ... if he doesn't say anything in a while, then an e-mail will be sent to request a manual update to that database ....

Link to comment
Share on other sites

The best way to report problems involving goofy reporting addresses is to send the information, including a "TRACKING URL," to the deputies at deputies[at]admin.spamcop.net
Thanks Don, email sent.
Link to comment
Share on other sites

  • 3 weeks later...
  • 1 month later...
K... so someone please riddle me this:

Why does SpamCop choose the 'catch all' of postmaster[at]onet.ru for this report, when the cached email address is valid? I see this quite often.

http://www.spamcop.net/sc?id=z2141145199z7...13e30a17cf68d8z

SC appears to use the abuse.net result which you can see by hitting the [refresh/show] link in the parse - http://www.spamcop.net/sc?action=rcache;ip=91.189.242.249 (no record, using default).

Yeah, seems a bit wacky, the routing details show noc[at]onet.ru too - http://www.spamcop.net/sc?action=showroute...49;typecodes=17 - noting that is an admin address, not abuse as such.

If the admin address is more responsive the deputies should be alerted to change it, otherwise the default is postmaster when there's no abuse[at] I guess.

Link to comment
Share on other sites

See, that's what I don't understand. If there's no abuse.net address, shouldn't the system send to the admins or NOC addresses? I'm not sure what the figures are, but it seems to me SC would get a faster response (if any) compared to sending to the catch-alls that may never be checked.

Link to comment
Share on other sites

See, that's what I don't understand. If there's no abuse.net address, shouldn't the system send to the admins or NOC addresses? I'm not sure what the figures are, but it seems to me SC would get a faster response (if any) compared to sending to the catch-alls that may never be checked.
Maybe. Postmaster has a certain degree of functionality assumed, SC reports are intended to be helpful, not abusive, but just how they might be regarded by other registered addresses (when there is no registered abuse address) I have no idea - they are, after all and in this circumstance, unsolicited.

The system (at about 750 million reports a year) has to be largely automated and I'm guessing it needs to be conservative for that reason. I know that alternative report routing will always be considered - it just has to be justified/demonstrated as being 'better' than the existing/default where 'better' includes some assurance of acceptability to the ISP/network (who always has the option of refusing reports anyway - per http://www.spamcop.net/fom-serve/cache/92.html ).

Link to comment
Share on other sites

See, I think that's counterproductive. If the listed people are the NOCs and/or the Admin for the ISPs/Hosts, they are responsible for the ISP/Host, so we should send that notification of abuse to all involved and let THEM say whether or not they want it.

Maybe I'm being overzealous on this and maybe people are checking the catch-alls, but I really think the admins/NOCs should be notified of abuse on the IPs they administer. Otherwise, they're not really deserving of the title, are they?

Link to comment
Share on other sites

...Maybe I'm being overzealous on this and maybe people are checking the catch-alls, but I really think the admins/NOCs should be notified of abuse on the IPs they administer. Otherwise, they're not really deserving of the title, are they?
Couldn't agree more on what/how Admins/NOC *should* do/act Brandon - perhaps we're in a minority, but that wouldn't make us wrong. I wonder how many paying users add such addresses. It is a bit hard to get away from the dead hand of the default determination though, that will always be the overwhelming influence on report routing.

It would be good to know the official take on all of this, to be assured that this stuff is considered and reviewed and isn't just on 'autopilot'. Well, we know Ellen and Richard (for two) are flat out on monitoring stuff and inserting over-rides as required, generally providing intervention as required so it's not exactly a matter of being stuck on autopilot. But I just don't know enough.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.


×
×
  • Create New...