Jump to content
Sign in to follow this  
DavidT

Technical details schizophrenia

Recommended Posts

I recently went through the process of setting up all my mailhosts and now I'm seeing some rather odd results from Quick Reporting.

Specifically, when I quick report a batch of my Held Mail, I get several "SpamCop Quick reporting data" messages (which is normal, it rarely all arrives in just one), but the first one respects my Preferences setting of "Simple output," while the second one is not respecting that setting, but rather acting as if I had "Show technical data" (AKA "Show technical details") selected.

This never happened before I set up mailhosts, so that's why I'm initially starting this Topic here in the Mailhosts forum. It's happening fairly consistently, and is a problem, in that if I run a large number of Held Mail items through Quick Reporting, I don't want to wade through all the extra details to make sure that reports are going to the right places. I also archive all of those "reporting data" emails, so it's also a concern about the size of the messages.

Has anyone else experienced or reported this phenomenon?

DT

Edited by DavidT

Share this post


Link to post
Share on other sites

I seem to remember a thread about this a couple of months back but don't think we got an answer to it. Just looked quickly and could not find it.

The theory (if my tired brain is remembering properly) was that messages that did not have forgeries were showing the quick data but ones with detected forgeries were showing the technical data. Your post seems to indicate something different, however.

You could add this to your list of problems to keep asking about ;)

Share this post


Link to post
Share on other sites
I seem to remember a thread about this a couple of months back but don't think we got an answer to it.  Just looked quickly and could not find it.

Thanks for the tip...I'll try some searching.

The theory (if my tired brain is remembering properly) was that messages that did not have forgeries were showing the quick data but ones with detected forgeries were showing the technical data.  Your post seems to indicate something different, however.

Some of them show "Possible forgery. Supposed receiving system not associated with any of your mailhosts" but others don't. Here are some of Tracking URLs that all came in with Technical Details (but they shouldn't have):

http://www.spamcop.net/sc?id=z657122626zbd...3e4508d72889d3z

http://www.spamcop.net/sc?id=z657122611z7f...fc8e7d3596de5bz

http://www.spamcop.net/sc?id=z657122598z82...2436009e6b80c0z

http://www.spamcop.net/sc?id=z657122575zac...ef683c0680f929z

http://www.spamcop.net/sc?id=z657122564za7...7ef8a1f4035c5bz

You could add this to your list of problems to keep asking about ;)

I probably will! The issue with Held Mail not expiring has been resolved. Most of the others seem to be bugs with SpamCop's installation of Horde/IMP.

DT

Share this post


Link to post
Share on other sites

No idea what to search on .. my recollection was something along the lines that if the parse went through cleanly, there'd be the short report .. if there was any kind of an issue, it would default to Tech Details on ... Looking at your examples, the only thing I can see "in common" is that all include a dev/null address, but I can't recall that being part of the issue. A couple of them have "could be forgeries" but others seem to have been "clean" parses .... again, I know this is no help, just offering what I thought I remembered ..just wish it would have agreed with your samples ...

Share this post


Link to post
Share on other sites

I know I see something similar in my setup. I use tons of addresses on my domain (basically, creating mail addresses based on company name, or other things, so that I can tell when people sell my address -- though I set my catchall to /dev/null to avoid dictionary attacks). When I set up the mailhosts, it only wanted to do one address per route, and seemed to overwrite if I tried adding more. So if the address is the one that the mailhosts is set up for, the output is much more verbose than if it is an address that it is not set up for. Very weird...

Share this post


Link to post
Share on other sites

JEV,

Fascinating observation...I'll do some testing. In the meantime, I've found the old, unresolved topic:

Reporting preferences; Technical Details, Technical Details random behavior

I just ran a batch of exactly 100 items through Quick Reporting, and this time, they all were handled properly, showing only the "simple output." I'll add to this topic when I receive some more that are showing the technical details, which goes against my settings, and is therefore probably a BUG with the Mailhosts System Beta Test.

DT

Share this post


Link to post
Share on other sites
I know I see something similar in my setup.  I use tons of addresses on my domain (basically, creating mail addresses based on company name, or other things, so that I can tell when people sell my address -- though I set my catchall to /dev/null to avoid dictionary attacks).  When I set up the mailhosts, it only wanted to do one address per route, and seemed to overwrite if I tried adding more.  So if the address is the one that the mailhosts is set up for, the output is much more verbose than if it is an address that it is not set up for.  Very weird...

16980[/snapback]

Just a point of clarification.

The email address that is displayed int the Mailhost screen actually has very little value. It is simply the last address that was registered that uses the listed mailhost. When you register one email address you have actually registered every email address that uses that same MailHost. So in reality, nothing is actually being overwritten from a functional point of view.

It would have probably been better to change the description of the email addresses to "last address registered"

Share this post


Link to post
Share on other sites
Just a point of clarification.

The email address that is displayed int the Mailhost screen actually has very little value.  It is simply the last address that was registered that uses the listed mailhost.  When you register one email address you have actually registered every email address that uses that same MailHost.  So in reality, nothing is actually being overwritten from a functional point of view.

It would have probably been better to change the description of the email addresses to "last address registered"

17001[/snapback]

I'm probably thinking of things wrong again, then. Any address at my domain should be using the same MailHost, but I get the two different types of output, depending on whether the spam went to the address listed or not. Which doesn't seem to me to mesh with what you listed above. So I'm going to guess that I'm actualyl doing something wrong. Any ideas on how I can correct it? :)

Share this post


Link to post
Share on other sites
I'm probably thinking of things wrong again, then.  Any address at my domain should be using the same MailHost, but I get the two different types of output, depending on whether the spam went to the address listed or not. 

No, I think you're OK...dbiel was just clarifying the way it is supposed to work, but you and I have both experienced evidence that there's something wrong with the system. I'm still running tests.

DT

Share this post


Link to post
Share on other sites

As DavidT said, this is the way is should work.

There may be a problem with mailhosts but I do not think that is the case.

It may be that the problem lies somewhere else and just seems to be related.

In either case, it is a problem that needs to be checked out which is beyond my ability.

Share this post


Link to post
Share on other sites

Looking at these posts looks like the problem is actually with the parser but related to the mailhosts configuration in that the parser takes a different "track" if the mailhost config is in play.

Share this post


Link to post
Share on other sites

Another possible explanation would be like this:

1. I use Quick Reporting to report a group of messages

2. sometime before receiving the results of the Quick Reporting (which can take some time), I go to the web-based reporting form and run a manual report on something I'm curious about, temporarily using the "Show technical details" option

3. the parser isn't done yet with my entire batch, so this change from "simple output" to "tecnical details" affects the rest of the batch and they get processed that way

That *might* have happened. Or, a similar scenario might be:

1. I use Quick Reporting to report a group of messages

2. someone posts a Tracking URL in the Forums and I click on it

3. the parser isn't done yet with my entire batch, but it senses my temporary change from simple to technical (all Tracking URL viewing is performed in "full details" mode, regardless of the user's preference settings), so it changes the mode in the midst of the parsing run

I'll have to run some more tests to see if either of these produce the anomalies that have been reported.

DT

Share this post


Link to post
Share on other sites

I do believe one of the ways to save the Technical details setting is by running a manual parse from the web page.

Share this post


Link to post
Share on other sites
I do believe one of the ways to save the Technical details setting is by running a manual parse from the web page.

Yes, but only if you place a checkmark in the "Show technical details box." That setting is persistent, in that it gets "remembered" and also alters your actual Preference setting, which is a little stupid, in that the checkbox should be for a temporary override of the Preference, and not something that alters the saved Preference, IMO.

DT

Share this post


Link to post
Share on other sites

Once you have mailhosts certain parses produce more technical data than others and there is no way to turn off that data. It's just the way that the system works.

Share this post


Link to post
Share on other sites
Once you have mailhosts certain parses produce more technical data than others and there is no way to turn off that data. It's just the way that the system works.

OK...I'm the "logical" type, who likes to know the whys and wherefores, but I'll just let this one go. :-)

DT

Share this post


Link to post
Share on other sites
Once you have mailhosts certain parses produce more technical data than others and there is no way to turn off that data. It's just the way that the system works.

17085[/snapback]

Well, if that's the case, then everything might be working correctly. Since this is exactly what I'm seeing. Any way of telling which will show more technical data than others? I'm curious because I'm still not 100% sure that things are all set up correctly on my end, and that woudl clinch it. Thanks.

Share this post


Link to post
Share on other sites
OK...I'm the "logical" type, who likes to know the whys and wherefores, but I'll just let this one go.

Well....maybe not. :P

My last two (two and 1/2, actually) Quick Reporting batches produced data emails containing full technical details, after going three days only seeing the "simple output" in the reports. I think this is really a bug in the system and isn't happening by design, but oh well...

DT

Share this post


Link to post
Share on other sites
Well....maybe not.  :P

My last two (two and 1/2, actually) Quick Reporting batches produced data emails containing full technical details, after going three days only seeing the "simple output" in the reports. I think this is really a bug in the system and isn't happening by design, but oh well...

DT

17198[/snapback]

Do you think it might be server dependant ie the specific server that the parse happens to run on.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×