Jump to content

bleeb

Members
  • Posts

    6
  • Joined

  • Last visited

bleeb's Achievements

Newbie

Newbie (1/6)

0

Reputation

  1. Would be happy to, but regretfully, no firm proof. Only statistical (roughly 10% drop in volume, after excluding this domain from LARTs for a couple of weeks.) Also, there's been anecdotal discussions about some of the more prolific spamvertising domains (i.e. chinatietong, for one), passing LARTs back to spammers, over the news groups.
  2. I ran into an interesting case, today. The originating server of the spam, and the web sites spamvertised, were all run by suspected black hats. In the past, LARTing them just resulted in more spam. If all LART check boxes were unchecked, the parser wouldn't do anything with the report, and it would stay stuck in the incomplete queue. Suggestion: Have some way to indicate that report can be counted towards the BL, but don't send LARTs to originating server's contacts. (To avoid running into problems because of all the people who just check everything, maybe the first check box, defaulting to on, could be "add originating mail server to BL".)
  3. Sorry. Didn't realise you'd merged it. Tthought I'd posted it in the wrong place since it seemed to be a separate issue, as it had to do with a "normal" e-mail address that doesn't have the problem with multiple relays within the ISP between public MX and delivery to the user. That was the part that had me confused: The lack of indication as to what was holding things up (slow server or mailhost config problem) when no responses were seen for spam submitted. This was spam received by a normal (non-relayed) e-mail address with headers not being pre-munged. In the end, it looks like there was one attempt at adding a server to the mailhost list that hadn't been properly cancelled, and removing recent additions one at a time till the culprit was located seems to have done the trick. I guess the FAQ/pinned item warns this can happen, but some indication that it has (and that it's not some other cause) might be a useful feature to add (i.e. "You've sent probes to your e-mail accounts on n servers, but haven't returned x of them to mailhosts for processing.")
  4. Is there some way to tell whether you've "completed" configuring an address, other than receiving a confirmation e-mail? While struggling through the process a few times, the "configuration: success/failed" e-mail wasn't always getting through, and it wasn't obvious from the configuration web page whether all of the "sends" had been either completed or cancelled, or whether there was one open that was holding up spam processing. (Might want to add the answer to the mailhost config FAQ.) Thanks.
  5. Thanks for the responses, but after thinking it over, I decided not to risk the wrath of the IT gods by making public these details regarding the company's internal network structure (or telling people outside the company, even though one presumes the deputies are trustworthy! Maybe I'm being overly paranoid about security. Instead, I mailhosted (apparently succesfully) using headers only up to the public MX, omitting details regarding internal routing. Guess I'll have to remember to do the same when submitting. (From the web site, this doesn't appear to fall afoul the "no modifications" rule, although I be happy to hear dissenting opinions.) One thing I'm somewhat curious about is whether this isn't a common situation for larger organisations. The e-mail in question was relayed through a commercial 'high-reliability' service with redundant servers and multiple connections, an anti-spam server, an anti-virus server, and Sarbanes-Oxley compliance checking (whatever that means) before reaching one of several end-user mail servers. Or maybe it's just too complicated to automate.
  6. I just tried to add my work e-mail to my mailhosts, and wasn't sure what to do, after several attempts. (Read all the pinned items in this forum, and mailhosts portions of the help pages. If the answer is there, it wasn't obvious.) Figured I'd ask here, since SOMEONE else must have figured this out, before I bug the overworked deputies. Problem: My incoming mail passes through multiple internal relays, before ending up at the mail server I actually download from. Mailhosts didn't like all the domains and relays it saw in the header of the confirmation, and I don't have any way of accessing mail at each intermediate relay, since anything that gets there automatically gets passed along the chain and ends up with the same full set of relays listed in the header. Pruning the header appeared to make the mailhosts config unhappy, as well. Any pointers? Thanks.
×
×
  • Create New...