Jump to content

jcrm

Members
  • Content Count

    14
  • Joined

  • Last visited

Community Reputation

0 Neutral

About jcrm

  • Rank
    Member
  • Birthday 06/29/1970

Contact Methods

  • Website URL
    http://
  • ICQ
    0

Profile Information

  • Location
    Midlands, UK
  • Interests
    reducing spam
  1. jcrm

    Is SpamCop missing some ISP's in reporting?

    perhaps there could be another RBL that keeps track of those addresses for which spamcop reports are ignored.
  2. rfc2821 doesn't seem to mention the requirement for rfc2045 headers, so in 7 bit clean messages with line lengths of less than 1000 characters you need not use it. What gain do you/pegasus perceive from only accepting rfc2045 messages? Personally I'd be glad to see MIME discarded completely, but then I can easily drop a file on a server and send someone a URL
  3. I quite agree -- rejecting text only messages seems pretty daft, but this appears to be software for MSWindows
  4. jcrm

    matching the IP of senders

    rfc2821 (not itself a standard) proposes a syntax, but as this was "only" written in 2001, and the last release of qmail was made in 1998 this isn't going to help. you will end up with a cascade of regular expressions if you know all your candidate headers are coming from qmail, then the regexp is something like ^Received:\s+From\s+(\S*)\s+(\(HELO\s+(\S*)\)\s+)?\(((\S+)[at])?\[?((([1-9]?[0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])\.){3}([1-9]?[0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5]))\]?\)\s+by\s+(\S+)\s+with\s+\S+(\s+for\s+\S+)\s*;\s+((1|2)[0-9]|[1-9])\s+[A-Z][a-z]+\s+[0-9]{4}\s+[-+][0-9]{4}\s+$ where \1 is the reverse lookup, \3 is the given name if any, \5 the ident response and \6 the ip address. I can't remember any patches to add ID or VIA information to the header so I have not included them to "keep it simple" for a modernish sendmail you have ^Received:\s+from\s+(\S*)\s+\(((IDENT:)?(\S+)[at])?(\S*)\s+\[?((([1-9]?[0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])\.){3}([1-9]?[0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5]))\]?\)\s+by\s+(\S+)\s+with\s+\S+(\s+id\s+\S+)(\s+for\s+\S+)\s*;\s+[A-Z][a-z]+,\s+((1|2)[0-9]|[1-9])\s+[A-Z][a-z]+\s+[0-9]{4}\s+([A-Z]+|[-+][0-9]{4})\s+$ where \1 is the given name or the reverse lookup if no name given, \4 the ident response, \5 the reverse lookup and \6 the ip address.
  5. This scenario would rather suggest that these servers were mis-configured, thus breaking the chain somewhere during the parse and looking like the injection point. and where might this be documented, especially in the suggested case above? I prefer "not behaving as spamcop's parser expects" to misconfigured. Not being able to see the headers for the message, I can't comment further. But should this be the case, and the servers were innocently forwarding spam, those addresses that have reported spam that came through these servers wouldn't get them blacklisted as they would have registered the relevant path
  6. possibly the spams were being passed through the servers as part of their normal email forwarding function. If this were the case then the spam would have been misreported, and Ellen was correcting the mistake (the new mailhost system would take care of this)
  7. oh.... my mailhosts appear to have fallen off as I had a waiver I wouldn't have deleted them, but they seem to have gone. should i resubmit, or should i leave things alone so people can try to work out why?
  8. coo, these guys got spheres of steel. It's my first spam via spamcop, I'm so excited!
  9. jcrm

    The future of spoofed spam looks bad

    People don't care about the revese lookup and HELO matching because it gains nothing. If it were used by most people to validate messages the spammers would fix it, rather than faking it in order to confuse novices trying to work out where the spam came from. Personally I think name in HELO should be phased out, it made sense for RFC788 as you possibly didn't have the calling parties address in your host.txt file (this was pre-dns) and it made your logs nicer, nowadays it's only there for human consumption, and only humans get misdirected by spammers using it to lie rfc2821 says you shouldn't block it because it doesn't match. there are some legitimate situations where the sending server doesn't know its presented IP address. in short: use this as a test in part of a weighted system, but don't treat it as black and white.
  10. jcrm

    Why Am I Blocked FAQ

    I speak only for myself, but abuse admins are a lazy bunch*. If you want me to look at your complaint, you had better have sent me enough of the message so I can see wether it is definately spam, or only possibly spam, or probably legitimate. Then there had better be properly formatted headers which, while email addresses may be "munged", had better be pretty much intact so I can check against our logs to see if it really happened (which unfortunately means I can dig out the email address - sorry). If you don't send me what I need, I'm probably not going to look at it. I may send you a 3 word email "not enough info" Don't tell me you expect someone who deals with spam to click on a weblink with a code in it just because it says there has been some spam sent. *not really lazy, it just looks that way. Dealing with abuse is just an "extra" part of the job for all of the people I know that do it. If you assume that handling abuse is all we do, then the amount of time we are prepared to spend on it makes us look pretty lazy. Miss Betsy, while i think this idea of yours is bad, I think the FAQ does a fine job of informing a user without insulting an admin.
  11. jcrm

    The future of spoofed spam looks bad

    I was kind of guessing that this is the type of data you had in mind when I asked if DNS was what you were actually talking about. DNS stands for Domain Name Server and used to translate your typed in URL to an IP address, nothing more. The MX records you're referencing are only seen when you do a DIG type operation, which gets you back a whole passle of information. And the catch there is that although you would think that the data contents found in these records would be standardized, they aren't, I have to disagree with you. DNS records are highly standardised, and a SPF record could be created, if IANA were to assign an RR TYPE code to it. I think you are confusing the view your tools give you with what really happens. (ie nslookup gives you an ip address for a name, and then theres dig which gives you a whole lot more stuff) The main probem is that legitimate mail doesn't just come from the server of the ISP that has the domain. If you have an email forward set up, mail is resent from the server that is doing the forwarding, so mail from bill[at]msn.com would reach me[at]vanity.com, this server would try to forward mail to customer15322[at]isp.com, which would look up the SPF record for msn.com and drop the mail as spam coming from an unauthorised host. similarly when you send mail to a mailing list the server sends it out as if it came from you to everybody subscribed to the list. this would not reach you if your recieving server was SPF aware. Some web sites send email on your behalf - greetings cards, send this page to a friend, - and while I would slap anyone who passed the email address I gave them to communicate with me i recognise this as legitimate.
  12. jcrm

    The future of spoofed spam looks bad

    I guess you don't subscribe to mailing lists
  13. I don't mind ISPs main outbound MXs being listed, but the new system appears to prevent the IP addresses that send to those MXs being listed. Our outbound relays only accept from our customers and we check them against spamcop before accepting their mail. This helps protect the internet at large, and /helps/ keep the outbound servers from being blocked, and therby affecting innocent senders I suppose the question is how does a relay get its received lines trusted by spamcop?
  14. someone has started adding single numbers in the middle of their headers. This breaks SpamCops parsing. (I guess any string of characters without a : would have the same effect)
×