Jump to content

gnarlymarley

Memberp
  • Content Count

    460
  • Joined

  • Last visited

Posts posted by gnarlymarley


  1. 49 minutes ago, RobiBue said:

    What if... there is/could be a way to check how old an email account is (when it was created) ... Serious Callers Only (yeah, been reading Iain Banks lately ūüėČ) won't use throwaway (recently created) emails to sign up and post in SC (at least I don't think so) unless they are spammers...ÔĽŅ

    I am not even sure how the coders would detect how old an email is.  I am not even sure this information is available.

    51 minutes ago, RobiBue said:

    Aaaanyway, so spammer creates emails galore on gmail/outlook/protonmail/yandex/whatever and tries to sigÔĽŅn uÔĽŅp in forum. ForÔĽŅum says your email is too new, you need approval from admin to post new posts.ÔĽŅ I know, you mentioned bÔĽŅeÔĽŅfore about legitimate users that want to post, but their email addresses (on the aforementioned big email houses) are usually long established. So the email address age would prevent this spammer from posting right away, and his address could be placed on the ban list for future attempts...

    From what I recall, the forum is double opt-in.  I don't think it lets them post until they verify their email.  That verification could be why it takes 3 to 20 minutes between the post and the sign up.  Spammers are grabbing both domains and abandoned email addresses and have been caught using those in their spams.  What is there to stop them from using what is considered an old email address when they sign up?

    5 hours ago, Lking said:

    The most of the emails today are gmail and outlook. This looks to be true historically with lots of protonmail.com,  mail.com, and yandex.com  The email(s) used with the one IP use twice to post were mail.com and faithmail.org.

    That does not leave any good way to block them.


  2. 16 hours ago, RobiBue said:

    I figure, since the ‚Äúspam-poster‚ÄĚ needs an email account to sign in, these people have tons of throwaway addresses, since they can only use them once. (I am curious on how many addresses use the same domain, and thus prevent them, depending on the domain they use, to even create a SC account. Of course, if they use throwaway gmail, yahoo, hotmail, et.al. accounts, that wouldn‚Äôt be feasible...)

    What an interesting thought.  Though I  wonder if they have a stash of thousands of stolen accounts they have to use or if they might be using their hundred domains (like the ones I see in the URLs) for their signup email.


  3. 10 hours ago, Lking said:

    Beefing up the front end to keep out the bots seems to be the only acceptable solution, IMHO.  Holding the first post it seems would discourage first posters that have been "blocked by SC" or are trying to deal with spam incoming to their system, both a primary audience.  Blocking IP's or blocks of IP's has the same affect. (yes there have been lagit posters from Russia and India)

    Richard had said he did this with the captcha on May 19, but I don't think I saw any change.  I believe this entirely posted by humans.  If it was a robot, the account creation would be around

    1 hour ago, Lking said:

    Sorting the 23 IPs that posted spam over night today show only 1 duplicate  post in "How To Use" otherwise the IPs are unique.  The most active was 4 post from 146.196.37.0/24  otherwise unique at that level.

    Sounds like they might be jumping around (if one person) the internet to avoid detection like they are with email spam.  Also could be that someone is using a VPN service.  I am fairly certain that it is at least two people posting the junk, but could be more.  (The language style seems to be only two different types.)

    The source code of HMTL (from http://forum.spamcop.net/profile/46580-hhhmax85/ on Rob's original example) seems to offer a datetime that appears the spammer is returning back later.

    <h4 class='ipsType_minorHeading'>Joined</h4><time datetime='2019-07-18T09:51:20Z' title='07/18/2019 03:51  AM' data-short='Jul 18'>July 18</time>
    <h4 class='ipsType_minorHeading'>Last visited</h4><time datetime='2019-07-18T09:55:53Z' title='07/18/2019 03:55  AM' data-short='Jul 18'>July 18</time>

    I am not sure if the account has someone returning about four minutes later is robot.  Other users I have looked at can be "returning" as much as 16 minutes later.  They either have a good randomizer, or else this is surely human.


  4. 6 hours ago, RobiBue said:

    Well, my idea wasn't to thwart the spammers... (ok, in a way it isÔĽŅ ÔĽŅūüėõ)

    I don't like the forum spam because as soon as it is posted, gmail has all forum emails marked with spam reputation.  At this point, I personally would prefer to thwart the spammers similar to bl.spamcop.net if possible.

    6 hours ago, RobiBue said:

    InstÔĽŅead, it would be meant to keep the ÔĽŅforuÔĽŅms "readable" after 3 or 4 users have reported the posts.ÔĽŅ
    They'd still be there if one really desires to read them, but they'd be hidden until they get handled by an admin.

    Ah, so maybe something automated.  If this were possible, I am all for automating any part of it so to limit human mistakes.

    6 hours ago, RobiBue said:

    Just my thought... and then Lking could even enjoy his carb-sugar-caffeine drink in a more leisurely mannerÔĽŅ ;)

    Seems like maybe some of the admins might be burning the candle at both ends at times.  I have seen more than one person make mistakes when it comes to cleaning up the spam in the forums.  Anything that might help out would be a plus.

    I am tempted to suggest that something similar to the SpamCop BL, where enough bad report and a user cannot post or sign up with a new account for 48 hours.


  5. Black Tiger,

    I see the period at the start of the domain name on the following line.  The parser in the past has had problems with that if you have mailhosts enabled.  If you submit it without the period (or put something in front or the period) or just remove that worthless Received line, it should submit.

    Received: from localhost (127.0.0.1) by .jlU2KPHsGNpygo@Brief.me id IoLDL6FfG7GE

  6. On 7/18/2019 at 5:35 AM, RobiBue said:

    Well, here is my proposal to alleviate the problem:

    Rob, I like your solutions, but I don't think they apply here.  As near as I can tell all accounts used in the spam appear to be mostly one and done.  I have noticed that they have two posts at most, but most of them are created to post single content.  Sometimes the same exact thing is posted twice, but it seems to be by different accounts.  The account creation and the post appears to be within about ten minutes.  The reason why I see only one post could be because Lking limits their posting, so they appear to create a new account and move on.  I think Richard might be getting it late at night, while Lking has the daytime.

    The forum admins have also changed the captia, so I don't think it is automated spam.  It appears to be fully human since they get through all the hoops that the admins have applied so far.


  7. 3 hours ago, RobiBue said:

    is there a reason why the first From line doesn't have a colon ":"

    
    From bounce@menshealth.com  Mon Jul  8 01:35:59 2019
    Return-Path: <bounce@menshealth.com>
    X-Original-To: x
    Delivered-To: x

    in my book, that would be a reason for failure..

    The first line is not supposed to have a colon.  It is the mbox begin header that allows multiple emails messages to populate a single file (I believe this is RFC4155).  I myself have submitted these in the past without the parser hanging, but I do not have an example of a good parse readily available.  When I come across one, I can post the proof that the parser is okay with the first line.

    A little further down, I see the proper From: with the colon.

    From: Best deal

    Here is a good parse that has the mbox line intact: https://www.spamcop.net/sc?id=z6539474280z193289084e1307447d9bce67061eecfbz


  8. On 6/21/2019 at 7:54 AM, Spamnophobic said:

    Hi MIG and everyone, I cleared all unreported spam, re-registered my mailhosts (with success confirmations from SC) and submitted the spam again. Unfortunately with the same result:

    Spamnophobic, The problem seems to be the existence of a dot at the start of the hostname that seems to be stopping the parser, as can be seen by the other forum link below.

    It appears to be the following line:

    Received: from localhost (127.0.0.1) by .z2bozghMJqWR3w@amazonses.com
    

    Sounds like your options are to submit without mailhosts, or to just remove that dot before you submit.


  9. On 6/21/2019 at 9:30 AM, gnarlymarley said:

    I get this occasionally

    I have located "Reporting form not loading fully afterparsing spam" from 2018, so this issue is pre-V5.0.  I don't see any solutions on that post.  My solution was to have two account setup and if I see a dot at the beginning of the hostname, I send the spam to the non-mailhosts account.

    On 6/8/2019 at 7:05 AM, gnarlymarley said:

    I suspect the function that they expect that rather than the parser dying, it would come up with something like "Not one of your mailhosts"

    By this comment, I meant that it would be nice if the parser was fixed...


  10. On 6/20/2019 at 5:41 AM, MIG said:

    (3) No, I'm pretty sure I've seen similar commentary from other folks - never fear Jelmer, you're never alone!ÔĽŅ

    Jelmer, I get this occasionally too.   I had some communication with the SpamCop Admins in 2017, but I am not sure if that is when I first saw it.

    Being that some folks called it a dot or period or {DOT}, it does make searching the forum difficult.  Since spammers do not always get the reports (their ISP does and doesn't always pass it on), they probably do not know for sure what is caught by spamcop.


  11. Another reason why I would prefer an automated solution over the manual one is that the current solution can override any whois lookup attempts.  Once an entry is made manually, it will constantly need to be manually updated as it can prevent the fresh "whois" link from gathering new contacts.  If an IP range is passed back and forth between (for example) APNIC and ARIN, each pass would require a manual update.

    If automated,  The system can either expire the cached entry or else the refresh whois link could pull in the updated contacts.


  12. On 6/10/2019 at 11:08 PM, lisati said:

    Sounds a bit like  "backscatter" where a provider has the "wrong" email address to use when sending out a bounce or other form of non-delivery report.

    MIG,

    This is one that does nearly sound legitimate and had me going for about 10 days now, but I think I have cracked it.  It appears that the bounce should be coming from 162.255.118.61 or 162.255.118.62 and not 54.240.8.31.  The MX record for client76701.host appears to be namecheap.com, not amazon.  The more I look at this, the more I think backscatter


  13. On 6/2/2019 at 4:26 AM, MIG said:

    The table table/pinned topic I'm "promoting" is for email addys that SC NEVER identifes and NEVER will

    I will explain further.

    Yes, I believe this does need to be updated as long as SC  is not identifying the proper email addys.  I also believe we should be able to figure out "why SC is not identifying the proper source" and we should be able to fix it.

    The "NEVER will" part needs human intervention with "both" the programmers to fix SC and also putting manual entries.  I believe if SC could be fixed, it would automatically determine "most of the proper addys", but there would still be a smaller percentage that needs to be manually entered (due to bad whois or some other circumstance).


  14. On 6/6/2019 at 7:31 AM, MIG said:

    So, unless I'm mistaken, we've concluded the parser can process if the . is removed and or can process using a NO-MAILHOSTS configured¬†ÔĽŅaccount.

    Yes.  I suspect the function that they expect that rather than the parser dying, it would come up with something like "Not one of your mailhosts".  Then they could continue their submissions with one account that has mailhosts enabled.


  15. On 6/6/2019 at 6:19 PM, MIG said:

    I'm trying to work out, if permission was granted, would the "allow" question be resolved?

    The answer to the permissions question would be not solved by a permissions grant since SpamCop goes to ARIN and stops.  It does not appear to be trying the other registrars.  As near as I can tell, the "Redirect to ripe" or "Redirect to apnic" or "Redirect to lacnic" or "Redirect to afrinic" that shows up is manually made entry from http://forum.spamcop.net/forum/39-routing-report-address-issues/ and not automatic.

    "whois xx.xx.xx.xx@whois.arin.net" (Getting contact from whois.arin.net )
       Redirect to ripe

    As a reminder here, this is happening with more than just RIPE as it is happening with all IP registrars.  It is most notably with APNIC, which has granted full permissions.  Also, I thought there was a whois copy at SpamCop using rsync that would be queried first, which would also


  16. On 6/2/2019 at 3:17 AM, gnarlymarley said:

    % To receive output for a database update, use the "-B" flag.

    If this does get looked at for implementation, then I would note that it appears AFRINIC is also doing this.  It might be wise to look at an automatic implementation that could work for any registrar if they turn this on.

    %       To receive output for a database update, use the "-B" flag.

    [refresh/show]

     Display data:


  17. 16 hours ago, MIG said:

    Last 1. " Why not submit to SCA?", I meant why not contact SC/Admin and ask them to implement automation of the "allow for whois referral when ARIN relocates an entire range to APNIC or RIPE".

    Ah, I thought you mean the IP range.  I did send a note to the SCA about the possibility of implementating this in Feb, when I had also them fixed the both a RIPE IP range and an APNIC IP range.  They thought it was a good idea.  I figure I would post it here for the rest to see just in case there was anything else I missed.

    5 hours ago, Lking said:

    This forum "New Feature Request" is the correct vehicle to pass suggested changes to the SpamCop tool.

     

    If I understood the SCA correctly at the time, this was thought to be in the works for the 5.0 upgrade.  I should also admit that I have never seen any typos from the manually fixed entries.

    One note, if this is implemented, I am not sure how far one would follow the referrers.  I know IPv6 on Hurricane Electric goes down to data put in on when a tunnel was created.  (AKA, but someone setting up a free account at the time.)


  18. At this time I am unable to find my RIPE IP (because the link is past 90 days), but it used to be accessible from https://www.spamcop.net/sc?id=z6524466667z591f1e62a326f6b7f0346018215c0821z.  If you have restore capabilities, you can find it.  I noticed this down on Feb 24th, so it would be that day or before.  If I can location the IP again, I can post it.  (I figure I can post it now and keep searching through all my spam to see if I can find it.)

    On 6/2/2019 at 6:20 AM, MIG said:

    "ReferralServer:  whois://whois.apnic.net", is this just specific for "apnic", or? 

    I am starting to think this is all of them and previously the SCA has been manually putting in the forward from ARIN to APNIC or RIPE or LACNIC, or AFRINIC.

    On 6/2/2019 at 10:18 AM, MIG said:

    I'm going to post about your post shortly, in the interim, may I ask please: "my whois program", which program are you referring to please?

    The whois program I was referring to is the one ran by the whois command on freebsd, but it also works on linux the same way.  That program detects the referrer and does a whois look up at the referred server.

    9 hours ago, MIG said:

    Why not submit to SCA?

    We are, but in this day and age with IPv4 runout, the registrars are dividing and passing small IP blocks back and forth and I imagine the intensity of those transfers will increase.  If this could be automated, it could alleviate the addition of human error (since most of us are getting it from the whois anyway) and also expedite the process of getting updated information.

     

    All


  19. Sorry about that.  Using a Code takes out the links.  Both sections I posted are from the same whois output.  (One is from above and the second from further down.)  If you look at [refresh/show], you can see that that it has the ReferralServer entry in the Display data area, but the whois chain stops at the ARIN output without apppearing to try to query APNIC.  I would expect SpamCop to follow the ReferralServer between registries like my whois program does, or when it forwards to LACNIC (Such as on [refresh/show] for 177.38.191.21).  (I have another example of it not following at from 158.140.160.0 below since the original IP has a manually entered entry on it Routing details for 150.107.103.51.)  The feature I would like added is to have it automatically follow the referral without any manual intervention.

    ..........................

    Parsing input: 150.107.103.51

    Routing details for 150.107.103.51
    [refresh/show] Cached whois for 158.140.160.0 : search-apnic-not-arin@apnic.net
    I refuse to bother search-apnic-not-arin@apnic.net.

    Using search-apnic-not-arin#apnic.net@devnull.spamcop.net for statistical tracking.

    Using last resort contacts search-apnic-not-arin#apnic.net@devnull.spamcop.net

    ..........................

    Tracking details

    Display data:
    "whois 150.107.103.51@whois.arin.net" (Getting contact from whois.arin.net )
    Found AbuseEmail in whois search-apnic-not-arin@apnic.net
    150.0.0.0 - 150.255.255.255:search-apnic-not-arin@apnic.net
    Routing details for 150.107.103.51
    I refuse to bother search-apnic-not-arin@apnic.net.

    Using search-apnic-not-arin#apnic.net@devnull.spamcop.net for statistical tracking.

    Using last resort contacts search-apnic-not-arin#apnic.net@devnull.spamcop.net

    ..........................

    Parsing input: 158.140.160.0

    Routing details for 158.140.160.0
    [refresh/show] Cached whois for 158.140.160.0 : search-apnic-not-arin@apnic.net
    I refuse to bother search-apnic-not-arin@apnic.net.

    Using search-apnic-not-arin#apnic.net@devnull.spamcop.net for statistical tracking.

    Using last resort contacts search-apnic-not-arin#apnic.net@devnull.spamcop.net

     


  20. RIPE whois now requires a "-B" for to be able to get actual email abuse email addresses from it.

    $ whois 91.219.88.121@whois.ripe.net
    
    [whois.ripe.net]
    % This is the RIPE Database query service.
    % The objects are in RPSL format.
    %
    % The RIPE Database is subject to Terms and Conditions.
    % See http://www.ripe.net/db/support/db-terms-conditions.pdf
    
    % Note: this output has been filtered.
    %       To receive output for a database update, use the "-B" flag.
    
    % Information related to '91.219.88.0 - 91.219.91.255'
    
    % Abuse contact for '91.219.88.0 - 91.219.91.255' is 'a.kazakov@ktstelecom.ru'

    If for any reason that the local RIPE whois cache is bypassed, it would be good to see this option added as a possibility so we can have SpamCop see the automatically capture the proper abuse addresses.

    [me@ ~]$ whois -h whois.ripe.net -- 'MP18628-RIPE'
    % This is the RIPE Database query service.
    % The objects are in RPSL format.
    %
    % The RIPE Database is subject to Terms and Conditions.
    % See http://www.ripe.net/db/support/db-terms-conditions.pdf
    
    % Note: this output has been filtered.
    %       To receive output for a database update, use the "-B" flag.
    
    % Information related to 'MP18628-RIPE'
    
    person:         Michail Pudikov
    address:        20 Partsyezda str. 11b
    address:        Tashtagol, Russia
    phone:          +7 3842 396006
    nic-hdl:        MP18628-RIPE
    created:        2010-09-20T09:37:31Z
    last-modified:  2016-02-25T13:06:00Z
    source:         RIPE # Filtered
    mnt-by:         KUZB-MNT
    
    % This query was served by the RIPE Database Query Service version 1.94 (WAGYU)
    
    
    [me@ ~]$ whois -h whois.ripe.net -- '-B MP18628-RIPE'
    % This is the RIPE Database query service.
    % The objects are in RPSL format.
    %
    % The RIPE Database is subject to Terms and Conditions.
    % See http://www.ripe.net/db/support/db-terms-conditions.pdf
    
    % Information related to 'MP18628-RIPE'
    
    person:         Michail Pudikov
    address:        20 Partsyezda str. 11b
    address:        Tashtagol, Russia
    phone:          +7 3842 396006
    nic-hdl:        MP18628-RIPE
    created:        2010-09-20T09:37:31Z
    last-modified:  2016-02-25T13:06:00Z
    source:         RIPE
    mnt-by:         KUZB-MNT
    e-mail:         noc@kts42.ru
    notify:         noc@kts42.ru
    
    % This query was served by the RIPE Database Query Service version 1.94 (WAGYU)
    
    
    [me@ ~]$

     


  21. We need to have SpamCop automatically detect when an entire IP range is transferred from one registrar to another.  Right now, there are a lot of manual updates being put in to get the reports to the correct destination.  This should be automated so that the correct whois entries can be detected without manual human intervention.
    
    Routing details for 150.107.103.51
    [refresh/show] Cached whois for 150.107.103.51 : search-apnic-not-arin@apnic.net
    I refuse to bother search-apnic-not-arin@apnic.net.
    Using search-apnic-not-arin#apnic.net@devnull.spamcop.net for statistical tracking.
     Using last resort contacts search-apnic-not-arin#apnic.net@devnull.spamcop.net
    
    I believe this is what it would detect in the code.
    
    ReferralServer:  whois://whois.apnic.net

     


  22. On 5/29/2019 at 10:01 AM, gnarlymarley said:

    I have seen occasional updates there

    This also does pose a question since much of the updates (such as the IP 150.107.103.51 shows) are manually entered from whois.  I believe should be automatically picked up from the whois system.  If the programmers could fix whois, I do not believe it will fully eliminate manual entries.  However, that would greatly reduce the amount of manual entries.


  23. On 5/20/2019 at 12:30 AM, MIG said:

    No, I wasn't referring to https://www.spamcop.net/sc?action=showroute x

    I was suggesting a pinned topic/table exist in SC Forum, collating addresses that SC doesn't identify BUT SC members have shown to be effective spam fighting endpoints.ÔĽŅ

    MIG,

    Yeah, that does need to be updated.  I have seen occasional updates there, which could be Richard doing the updates.  I would probably suggest more than one person who can do those updates.


  24. 37 minutes ago, Lking said:

    I would also suggest you contact your ISP to see if others share that IP.  If so others could be the cause of the listing. In either case, you should review your operation.

    Wilma,

    I have also seen routers that had been hacked.  You might always want to check your routers and IoT devices such as IP cameras.  Anything that is sharing that same IP could have been used to send the unwanted email.

×