Wazoo Posted October 17, 2005 Share Posted October 17, 2005 Work in progress ..... See Also: Entry in the SpamCop Wiki To start this out 'right' ... I asked the folks that deal with the specifics of the database, entries, and codebase of the MailHost configuration process for input to build a FAQ ... the response was a bit surprising ... However, I'll make it the first entry ... >I've been trying to work up an entry for "problems with the MailHost >Configuration process" for instance, but so many issues end with the >"resolved via e-mail" type solution ... I can't come up with the "answers" >for a FAQÂ .... There really aren't any FAQ type answers. All the user can do is follow proper procedures, such as registering main addresses first, and then register his forwarding services.Â He can't manipulate the details of his hosts on his own.Â There isn't anything he can do to help himself.Â If there are problems, one of us has to get into his account and manually fix it. All the FAQ can do is tell him to submit the Mailhost Waiver Request, or if that option isn't available, to write to us for help. That said; further entries provided below, added as I find the time (and info) to add to the list. Overview: Scenario: How does the MailHost data get added to the database? When you submit an address through the mailhost configuration tool the system does a mx lookup on the domain and sends an email to you through each of the mx's, regardless of priority. Generally a domain isn't going to have more than three mx servers listed, with all others being internal hops. Basically, you 'send back' each of the emails received and the system will work through the headers to identify each server involved in the mailpath between the sender (us) and your mailbox. Each server identified is added to the mailhost record for that domain. If a mailhost record already exists for that domain (i.e. another user on that domain) your account is simply pointed at that already existing record. If any new servers are identified they are added to the existing record. If a new server is found subsequently, yes we have to manually add it. Similarly, if the domain changes hosts we have to add the new servers and remove the old ones. (Taken from an RW response at http://forum.spamcop.net/forums/index.php?...ost&p=48584 ) Scenario II: extracted from a spamcop newsgroup post made 11Nov2006; SpamCop doesn't care about your email addresses or domains. The Mailhost system only wants to know about the hosts and servers that handle your incoming mail. You only need to register one email address per host to get that accomplished. You need to account for *all* of the hosts who provide you an email address, such as multiple ISPs, and webmail hosts like Yahoo or Hotmail, forwarding services like Bigfoot or Sneakemail, and others like alumni associations or professional associations that provide you an email address. Register your destination accounts where you collect your mail first, and then register the email addresses that forward into the final destination accounts. If you have multiple forwards, register the furthest away last. Don't worry about the names of the hosts SpamCop creates for you. The first guy to register a host gets to choose the name. Some of the choices are odd to say the least. Just ignore them. I rename the goofy hostnames when I find them. You can't report spam again until you get all your hosts registered. The Mailhost system completely changes the way SpamCop looks at your spam. The Mailhost system is an all-or-nothing deal. - Don D'Minion - SpamCop Admin - Problem: I have lots of email addresses that forward to one main email address. Everything is forwarded from there to SpamCop. I have registered the main email address with Mailhost. Do I need to register all the others? Solution: As long as they are not of the form from question 2, you have to set them up. Think of it as the mailpath rather than mailhost. Problem: If I've registered fred[at]example.com then presumably I don't need to register anythingelse[at]example.com?? Solution: That is correct, all addresses for the same domain would travel the spam path. Problem: Could having set this up wrong account for why SpamCop decided to: blacklist ALL my email today?! send reports to my ISP/e-mail host?! refuse to parse my spam submittals succesfully?! Solution: It is very possible, You should not do any reporting for any account not entered into your mailhost configuration as the parser works differently once mailhost is configured. Problem: Probe E-mail not Received: You may have actually received it, but it's been shuffled off to the Bulk/Junk folder by your ISP's filters. Check those folders first. Greylisting: Problem: Greylisting usually indicates that the first message is rejected with a temporary error code, which signals the sender (sending e-mail server) to try again and when that retry happens within a certain amount of time, the message is passed through. There is no human intervention required for greylisting. (Possible issue of the Sending re-try time period not fitting within the Greylisting receiving server's timeframe allowance) However, the SpamCop MailHost system is not the typical e-mail server, so there is no machine/software intervention here either. Probe e-mail is requested and sent, end of story. No retry at all. Solution: If possible, turn off Greylisting until the MailHost configuration is finshed. If possible, whitelist the SpamCop 'robot' address and try again. The currently seen data (and subject to change at any time) is (note slight mung): From: SpamCop robot <spamcop[at]devnull.spamcop.net> If neither of these are an option, run through the process twice, on the premise that the timeframe involved with the second probe e-mail arriving will fit into "the window of opportunity" for the retransmittal. Challenge/Response: Problem: Solution: If possible, turn off Challenge/Response until the MailHost configuration is finshed. If possible, whitelist the SpamCop 'robot' address and try again. The currently seen data (and subject to change at any time) is (note slight mung): From: SpamCop robot <spamcop[at]devnull.spamcop.net> Error Messages seen: Sorry, but SpamCop has encountered errors: Confirmation codes do not match: Problem: thus far has boiled down to "some" combinations of ISPs, e-mail server apps, end-user e-mail apps, end-user manipulations duting cut/paste/copy operations ... somewhere, somehow, for 'some' people, the contents of the probe e-mail get modified with some extra white-space chatacters (white-space example is a 'space' character, a 'Tab' character .. something that does occupy a spot in a string of text, but isn't exactly 'visible') Solution: (noting that the e-mailed response attempt apparently already failed) when copying the probe message 'data' ensure that the (critical) Confirmation Code line only includes the actual 'code" and not several inches of 'extra' trailing space. If necessary, start the 'marking' of data to be copied from the right end of that string .... Headers mangled Problem: examples thus far seem to be primarily those using web-mail applications, but one or two e-mail apps have popped up ... an attempt was made to "copy" the displayed probe e-mail data from a screen that wrapped lines ro fit into that display. The catch is that in the 'copy' process, 'hard' returns/line-feeds were included into the copied data. When submitted back to SpamCop, those newly wrapped lines do not match what a "good" e-mail header should look like. Solution: Attempt the e-mail response to the probe message first, as that "should" provide a 'true' copy of the probe e-mail. If a "copy" must be made, attempt to 'fix' the screen display so as 'not' to wrap long lines. If that isn't possible, then the copied data must be 'corrected' to put the long lines back into order. If you don't know what an e-mail header should look like, do not attempt this ... see the "first entry" in this document. Source IP not found. Problem: Your email host does not appear to correctly identify the sending IP of the email you receive. Issues thus far seem to be based on the user's hosting ISP changing their servers around, moving to new IP addresses, changing server names, ading new backup systems, etc. In one example, the issues was a mis-configuration of an inserted header line, specifically "the lack of whitespace between the server name and the square brackets around the IP address" ... Solution: Re-run the MailHost configuration process to add in these new/changed servers/addresses. Veify that the resulting spam parsing results are successful and correct. Problems not "fixed" at this point .. see the first entry for escalation. <a id="HeadersNF"></a><a name="HeadersNF"></a>Headers not found. Problem: For some unknown reason, the "X-SpamCop-Conf: SecretCode" line is being stripped out of the headers of the configuration test email. Solution: Copy the "X-SpamCop-Conf: SecretCode" line which is also found in the "Special codes" part in the body text, and pasted it just above the "From" address in the headers. or send an email to: service[at]admin.spamcop.net. Be sure to include the entire confirmation email with headers (use forward as attachment if possible) and use the following subject line: MailHost configuration error message Headers not found see forum topic: "Headers not found" when setting up Mailhosts -- for one host only ---- The stuff below here is just stuff I've copied out of existing discussions here that will eventually get incorporated into the final resulting FAQ entry ... ------- I am using SpamPal. One complaint that I've made to James Farmer (its author) is that the X-Spampal header has a huge number of trailing tab characters appended onto it. This makes this one line end up wrapping several times and making it look when viewed within a window like there are several blank lines after this header. See http://www.spampalforums.org/phpBB2/viewtopic.php?t=5028. ------------ Have you already completed the mailhost configuration for the individual accounts before MDeamon gets involved? A -> B -> C In this example, you need to configure account A completely first, then account B then finally acount C, basically adding a set of received headers at a time to the message. When you configure B, the headers for A are already recognized by the mailhost system. Edit: the above should read: you need to configure account C completely first, then account B then finally account A -------------- Got back both success and failure notices Trailing spaces, multiple MX records, or quiescent mail servers do not really explain getting BOTH a success and failure when using the e-mail submission method. The only problem I know of with multiple MXes is when one of them is dormant but available for disater recovery purposes (like for Postini). In that case the failure is that the secondary MXes did not respond, which makes sense because they are not connected to the internet at the time. But since email will not normally travel that path, it is not such a big deal until they enable the servers. 3) the ISP adding servers/deleting servers -- I would need to see your mailhosts specifically but in general if the new servers have DNS/rDNS/DNS that is rational it should be OK as long as the proper entries are in the domain. However it always helps to keep an eye on the parses and to write to us immediately at the address in the sig line if you see anything screwy. If you have a secondary MX that is not active for each address, you will get an error message for that server. The probe goes to each and every MX server for your domain to try and catch all paths the messages might take. There are domains for which "fallback" (lower priority) MX servers are listed that aren't actually configured to accept mail for the domain in question. This is not a good situation, in that instead of delaying the eventual delivery of the mail, a fatal error (500 level) is actually produced by the secondary server. If you properly confirm the successful probe, then you should be OK...unless your ISP decides to get their act together and properly configure the secondary MX, in which case, you'd need to go through the process again. If I were you, I'd complain to the ISP and either have them remove the unwilling server from the DNS records, or have them configure the secondary MX to actually accept mail for the domain, as it should be doing. If it was because your site uses multiple MX records, some of which are only enabled when the primaries are down (Postini does this), you should be all set. Just watch your parses closely for a while to make sure everything looks correct. Wazoo: When you send the original request, it sends a message to every MX it can find, which explains my reasoning. My Postini configuration at work has 4 MXes, 2 of which are not turned on except during a failover period. I received 2 of those errors because of that. If multiple e-mails were sent to configure a mailhost, then sometimes the first one would "fail," but then the next one would succeed, and the system seemed to retry the first on its own. At that point I assume that the mailhost is properly configured, assuming they all eventually got through? I don't understand all this, but I am assuming that a later e-mail gave the system information it needed to figure out an earlier one. ----------- 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. possibly/probably connected with; Lack of FQDN 'internal' servers --------- 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.") ------ Stopped at How many hosts to register - last post 11th April 2005 Source: http://forum.spamcop.net/forums/index.php?showforum=7 See Also Entry in the SpamCop Wiki Link to comment Share on other sites More sharing options...
This topic is now archived and is closed to further replies.