I have been using SpamCop for some time now, and I'd like to set up the mailhost system (since it seems all users are encouraged to do that). I've read in the FAQs that you don't need to register accounts that forward to your main account as long as they have the same domain name, but I'm not sure how specific "domain name" is. My main account is user[at]school.edu. I get emails forwarded there from foo[at]class132.school.edu, bar[at]department.class.school.edu, etc. Are those considered separate domain names, or can I ignore everything else ending in "school.edu"?
Also, as an aside, all of the spam I report will have been caught by the school's spam filter, which adds some headers identifying the type of spam and adds [SPAM:XXXXXXXXX] to the beginning of the subject. Is there any problem with reporting spam that has had these modifications from the original?
Thanks in advance.
Full Version: [Resolved] Registering forwarding addresses
I would personally register each of those subdomains, just in case any or all of them are handled by their own mail server.
I believe that the additional headers are not a problem as long as the server does not modify the existing Received headers that it receives.
I believe that the additional headers are not a problem as long as the server does not modify the existing Received headers that it receives.
Thanks for the quick response. I registered my main address successfully, and the others give me:
The email sample you submitted for foo[at]bar.baz.school.edu
appears to traverse more than one domain.
Please ensure that you configure each mailhost individually and in order.
I assume that means the redirection is handled internally and I don't have to worry about those subdomains?
The email sample you submitted for foo[at]bar.baz.school.edu
appears to traverse more than one domain.
Please ensure that you configure each mailhost individually and in order.
I assume that means the redirection is handled internally and I don't have to worry about those subdomains?
Please see http://forum.spamcop.net/forums/index.php?showtopic=7443 .... there has yet to be any notice made that the problem has been fixed yet.
If the actual server names would be provided, some analysis could be performed.
Failing that, there are MailHost Configuration Problem FAQs in place (short as they are), Pinned entries in this Forum section, etc.
If the actual server names would be provided, some analysis could be performed.
Failing that, there are MailHost Configuration Problem FAQs in place (short as they are), Pinned entries in this Forum section, etc.
QUOTE(Wazoo @ Nov 15 2006, 01:45 PM) 
If the actual server names would be provided, some analysis could be performed.
Sorry about that, I have a tendency to munge everything I post in forums. As far as I can tell, everything I use falls under one of the following:
berkeley.edu
imail.eecs.berkeley.edu
calmail.berkeley.edu
I have a feeling the first alone is fine, but I don't understand the technical details enough to figure it out any further.
In the meantime, I can continue reporting spam as long as I confirm none of the reports are going to berkeley.edu, correct?
Thanks again.
Domain Name: berkeley.edu
ucb-ns.nyu.edu reports the following MX records:
Preference Host Name IP Address
10 calmail.berkeley.edu 128.32.61.103
hmmmmm ....
11/15/06 21:53:21 Slow traceroute imail.eecs.berkeley.edu
Trace imail.eecs.berkeley.edu (128.32.42.119) ...
11/15/06 21:54:06 Slow traceroute calmail.berkeley.edu
Trace calmail.berkeley.edu (128.32.61.103) ...
http://www.senderbase.org/search?searchBy=...g=128.32.42.119
Addresses in berkeley.edu used to send email: Showing 1 - 50 out of 77
I really wish you had phrased that as "as long as the parse results are correct" ....
Please see http://forum.spamcop.net/forums/index.php?showtopic=7479
Went round and round tryng to find some of Don's last words on answering your question ... turns out that they werem't made in here ....
Ahhh, my confusion solved .... the above is in fact in here as I added it to the MailHost Configuration problems .. which I referenced earlier in this Topic .... only 20 minutes or so lost in trying to do the research to recreate the data here ...
ucb-ns.nyu.edu reports the following MX records:
Preference Host Name IP Address
10 calmail.berkeley.edu 128.32.61.103
hmmmmm ....
11/15/06 21:53:21 Slow traceroute imail.eecs.berkeley.edu
Trace imail.eecs.berkeley.edu (128.32.42.119) ...
11/15/06 21:54:06 Slow traceroute calmail.berkeley.edu
Trace calmail.berkeley.edu (128.32.61.103) ...
http://www.senderbase.org/search?searchBy=...g=128.32.42.119
Addresses in berkeley.edu used to send email: Showing 1 - 50 out of 77
QUOTE(jlrc @ Nov 15 2006, 06:31 PM)
In the meantime, I can continue reporting spam as long as I confirm none of the reports are going to berkeley.edu, correct?
I really wish you had phrased that as "as long as the parse results are correct" ....
Please see http://forum.spamcop.net/forums/index.php?showtopic=7479
Went round and round tryng to find some of Don's last words on answering your question ... turns out that they werem't made in here ....
QUOTE
From: SpamCop Admin
Newsgroups: spamcop
Subject: Re: Renewed MailHosts
Date: Sat, 11 Nov 2006 18:33:58 -0700
Message-ID: <2ctcl2143ngj0t8uejfvqd6kejp8h67upt[at]4ax.com>
Pop, please write to me directly so I can help you.
service[at]admin.spamcop.net
A new release of SpamCop was published Friday and it contains a
Mailhost "new host processing" bug. When SpamCop encounters a request
for creating a host when the configuration message (sample message)
traverses more than one domain, it balks. An emergency fix is on the
way, but it could easily take a week.
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.
Do NOT delete established hosts without conferring with me. Getting
them back at this time could be impossible because of the bug.
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 -
Newsgroups: spamcop
Subject: Re: Renewed MailHosts
Date: Sat, 11 Nov 2006 18:33:58 -0700
Message-ID: <2ctcl2143ngj0t8uejfvqd6kejp8h67upt[at]4ax.com>
Pop, please write to me directly so I can help you.
service[at]admin.spamcop.net
A new release of SpamCop was published Friday and it contains a
Mailhost "new host processing" bug. When SpamCop encounters a request
for creating a host when the configuration message (sample message)
traverses more than one domain, it balks. An emergency fix is on the
way, but it could easily take a week.
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.
Do NOT delete established hosts without conferring with me. Getting
them back at this time could be impossible because of the bug.
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 -
Ahhh, my confusion solved .... the above is in fact in here as I added it to the MailHost Configuration problems .. which I referenced earlier in this Topic .... only 20 minutes or so lost in trying to do the research to recreate the data here ...
QUOTE(Wazoo @ Nov 15 2006, 08:26 PM)
Domain Name: berkeley.edu
ucb-ns.nyu.edu reports the following MX records:
Preference Host Name IP Address
10 calmail.berkeley.edu 128.32.61.103
hmmmmm ....
11/15/06 21:53:21 Slow traceroute imail.eecs.berkeley.edu
Trace imail.eecs.berkeley.edu (128.32.42.119) ...
11/15/06 21:54:06 Slow traceroute calmail.berkeley.edu
Trace calmail.berkeley.edu (128.32.61.103) ...
http://www.senderbase.org/search?searchBy=...g=128.32.42.119
Addresses in berkeley.edu used to send email: Showing 1 - 50 out of 77
ucb-ns.nyu.edu reports the following MX records:
Preference Host Name IP Address
10 calmail.berkeley.edu 128.32.61.103
hmmmmm ....
11/15/06 21:53:21 Slow traceroute imail.eecs.berkeley.edu
Trace imail.eecs.berkeley.edu (128.32.42.119) ...
11/15/06 21:54:06 Slow traceroute calmail.berkeley.edu
Trace calmail.berkeley.edu (128.32.61.103) ...
http://www.senderbase.org/search?searchBy=...g=128.32.42.119
Addresses in berkeley.edu used to send email: Showing 1 - 50 out of 77
I'm afraid I'm going to need a little more explanation in terms of what conclusions are drawn from that.
QUOTE
I really wish you had phrased that as "as long as the parse results are correct" ....
Please see http://forum.spamcop.net/forums/index.php?showtopic=7479
Please see http://forum.spamcop.net/forums/index.php?showtopic=7479
Again, not to be dense, but what is the distinction? If all my valid mail is coming from something in the berkeley.edu domain, don't correct parse results mean that no reports are going back to my domain?
Thanks for the links regarding this problem, but I guess my question is do I even have to worry about it? From what I've seen so far, I'm guessing I don't have to add any of the other subdomains with this problem, so I should be fine with the configuration I have so far. But again I don't have the technical knowledge in this area to completely understand what's going on...
Based on your original query, all these addresses/hosts are in the same Domain. However, you then state that the error message described "appears to traverse more than one domain" says that either you've run into the current database/code problem or that the e-mail is handled in some way that in fact another Domain is sitting in the middle of things. Without seeing the actual headers, it's hard to guess from this side of the screen.
If everything were configured correctly, one 'could' say yes ... but ... for example, you have only chosen two of the 77 servers seen sending e-mail for/from that Domain. If you 'stop' now, things might work until you receive an e-mail from say .. a roving professor from another campus that ends up coming from another berkley.edu server that may not be configured/handled correctly ... still within the Doman, but not actually recognised as an 'acceptable Host' by the MailHost Configuration or the parsing code ...
The referenced previous Topics/Discussions, my attempted FAQ, the Pinned entries basically should have pointed you to the same 'solution' at this point ... e-mail to the Deputies, all data provided, MailHost in the Subject line ... such that one of the three paid-staff folks can get in and manipulate the database manually ... "us volunteers" can only get so far with this part of the system.
QUOTE
Again, not to be dense, but what is the distinction? If all my valid mail is coming from something in the berkeley.edu domain, don't correct parse results mean that no reports are going back to my domain?
If everything were configured correctly, one 'could' say yes ... but ... for example, you have only chosen two of the 77 servers seen sending e-mail for/from that Domain. If you 'stop' now, things might work until you receive an e-mail from say .. a roving professor from another campus that ends up coming from another berkley.edu server that may not be configured/handled correctly ... still within the Doman, but not actually recognised as an 'acceptable Host' by the MailHost Configuration or the parsing code ...
The referenced previous Topics/Discussions, my attempted FAQ, the Pinned entries basically should have pointed you to the same 'solution' at this point ... e-mail to the Deputies, all data provided, MailHost in the Subject line ... such that one of the three paid-staff folks can get in and manipulate the database manually ... "us volunteers" can only get so far with this part of the system.
I'll send them an email. Thanks again.
Handled by email.
I solved the problem by fixing the Berkeley.edu host so that it contains all the various schools and their servers. The different schools have their own networks, which makes it hard for SpamCop to keep everything under one host. Hence the "traverses more than one domain" error.
- Don D'Minion - SpamCop Admin -
I solved the problem by fixing the Berkeley.edu host so that it contains all the various schools and their servers. The different schools have their own networks, which makes it hard for SpamCop to keep everything under one host. Hence the "traverses more than one domain" error.
- Don D'Minion - SpamCop Admin -
Thanks Don ... explanation appreciated, especially that it matched my suspicions ..
The only thing not stated here is the cautionary note that the MailHost Configuration of jlrc's account is 'good' as of today, but there could be a moment in the future when existing servers are 'moved' .. new servers added ... such that one must not get too complacent about analyzing the parse output, checking a full parse every now and then if one gets into the Quick=Reporting everything mode ... best suggestion seen thus far, is to full-report one spam to make sure everything is golden, then Quick-Report the rest ....
The only thing not stated here is the cautionary note that the MailHost Configuration of jlrc's account is 'good' as of today, but there could be a moment in the future when existing servers are 'moved' .. new servers added ... such that one must not get too complacent about analyzing the parse output, checking a full parse every now and then if one gets into the Quick=Reporting everything mode ... best suggestion seen thus far, is to full-report one spam to make sure everything is golden, then Quick-Report the rest ....
QUOTE(Wazoo @ Nov 16 2006, 09:32 PM)
<snip>
The only thing not stated here is the cautionary note that the MailHost Configuration of jlrc's account is 'good' as of today, but there could be a moment in the future when existing servers are 'moved' .. new servers added ... such that one must not get too complacent about analyzing the parse output, checking a full parse every now and then if one gets into the Quick=Reporting everything mode ... best suggestion seen thus far, is to full-report one spam to make sure everything is golden, then Quick-Report the rest ....
...Great advice! Just one additional note of caution: depending on the route each spam takes to get to you on a given day, one may parse successfully and another (even if only seconds apart) may try to report your provider. Bottom line: IMHO any quick reporting must be done with extreme care and safest to not use it at all unless you know for certain that your provider's incoming e-mail environment is static.
The only thing not stated here is the cautionary note that the MailHost Configuration of jlrc's account is 'good' as of today, but there could be a moment in the future when existing servers are 'moved' .. new servers added ... such that one must not get too complacent about analyzing the parse output, checking a full parse every now and then if one gets into the Quick=Reporting everything mode ... best suggestion seen thus far, is to full-report one spam to make sure everything is golden, then Quick-Report the rest ....
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.