Jump to content

Mismatch between DNS blacklist and Web site


OlegD

Recommended Posts

This is where we need a server admin.

there are admins and there are admins. trying to read back through all of this, i can only find one reference to "not using exchange server" .... so if there was any specific guidance to be offered, is may not have appeared as the actual application/platform description hasn't been defined. (note the dialog about whether the SMTP/AUTH hack was applicable or not)

The talk about a back-up server is also missing a few facts. Is the back-up an in-house asset (and could thus possibly also have (access) to the user list) or under actual control of someone else (which would then fit the scenario of not knowing who the users are) ... Strategies would of course be different, and even these situations could be further changed if one was to ask just how often the backup MX came into use ... once in a blue-moon, maybe not really an issue at all, but if two or three times a week, perhaps there's something else that had ought to be looked at ....????

Miss Betsy had previously pointed out the survey mode of analyzing things about the whole traffic picture, citing previous conditions that the e-mail server had been scrutinzed repeatedly, but it was the quantum increase in traffic noted by looking at the firewall logs that finally identified that it wasn't "authorized traffic" that was at issue. The original poster responded to this by describing the massive amounts of customer data handled, citing the "impossible" task of sorting through all the bits ... missing that it wasn't the bits being discussed, it was the that the river had hit flood stage and no one noticed because they were discussing the color of paint on the town hall ....????

Link to comment
Share on other sites

This is where we need a server admin.

there are admins and there are admins. trying to read back through all of this, i can only find one reference to "not using exchange server" .... so if there was any specific guidance to be offered, is may not have appeared as the actual application/platform description hasn't been defined. (note the dialog about whether the SMTP/AUTH hack was applicable or not)

The talk about a back-up server is also missing a few facts. Is the back-up an in-house asset (and could thus possibly also have (access) to the user list) or under actual control of someone else (which would then fit the scenario of not knowing who the users are) ... Strategies would of course be different, and even these situations could be further changed if one was to ask just how often the backup MX came into use ... once in a blue-moon, maybe not really an issue at all, but if two or three times a week, perhaps there's something else that had ought to be looked at ....????

Miss Betsy had previously pointed out the survey mode of analyzing things about the whole traffic picture, citing previous conditions that the e-mail server had been scrutinzed repeatedly, but it was the quantum increase in traffic noted by looking at the firewall logs that finally identified that it wasn't "authorized traffic" that was at issue. The original poster responded to this by describing the massive amounts of customer data handled, citing the "impossible" task of sorting through all the bits ... missing that it wasn't the bits being discussed, it was the that the river had hit flood stage and no one noticed because they were discussing the color of paint on the town hall ....????

15326[/snapback]

1. I really doesn't ask any "specific guidances" that related to mail server administration. I was interested in site and blacklist mismatch and causes of listing (if any). I've got an answer.

2. Most of our backup MXses come into use nightly, when our clients switches off power in their offices :-) It's not a joke, unfortunately. Then, backup MX is a service, that provides some sort of fault-tolerance, and our clients pay for it. Additionally, we doesn't filter spam (with the exception of some DUL and ORDB checks), we only use SpamAssassin to rate mail messages, so user can decide, what to do with highly-rated mail.

3. One my client sent 5000 messages to different mailboxes in different domains, for example. Was it "flood stage of the river" or simply distribution of new pricelists to pricelist subscribers ? Did you ever administrate some large mail system ? If did, you should know, that such cases are real and not something unusual. Most of spam deliveries via such systems related to clients, not to security issues with mail system as such.

Link to comment
Share on other sites

1. I really doesn't ask any "specific guidances" that related to mail server administration. I was interested in site and blacklist mismatch and causes of listing (if any). I've got an answer.

I didn't say you did. I was responding to some quoted material from a post by Miss Betsy. But, as you want to make an objection, et me offer a bit of a quote from one of your posts which certainly has the appearance of you asking a question, to which Miss Batsy was responding;

Do you recommend to decline this scheme ? What fault tolerant delivery scheme you recommend in this case ?

Again, that sure looks like you were asking someone about something.

2. Most of our backup MXses come into use nightly, when our clients switches off power in their offices :-) It's not a joke, unfortunately. Then, backup MX is a service, that provides some sort of fault-tolerance, and our clients pay for it. Additionally, we doesn't filter spam (with the exception of some DUL and ORDB checks), we only use SpamAssassin to rate mail messages, so user can decide, what to do with highly-rated mail.

I would state that if the clients are turning their MX off every night, the issue you raise is on them.

3. One my client sent 5000 messages to different mailboxes in different domains, for example. Was it "flood stage of the river" or simply distribution of new pricelists to pricelist subscribers ?

Your client, only you would know if this is normal or not.

Did you ever administrate some large mail system ? If did, you should know, that such cases are real and not something unusual. Most of spam deliveries via such systems related to clients, not to security issues with mail system as such.

I have done and still do many things. Your opinion falls into the debatable range. Security is a major factor in the running of any e-mail system. spam comes from both customers and interlopers, received by all, so I'm really not sure what point you're really trying to make.

Link to comment
Share on other sites

One my client sent 5000 messages to different mailboxes in different domains, for example. Was it "flood stage of the river" or simply distribution of new pricelists to pricelist subscribers ? Did you ever administrate some large mail system ? If did, you should know, that such cases are real and not something unusual. Most of spam deliveries via such systems related to clients, not to security issues with mail system as such.

Again, since I don't have practical experience, I am not positive about my answer. However, I have read responses from admins who do administer large mail systems and they do seem to be able to differentiate between spam runs and legitimate bulk emailings though every once in a while a spammer slips through. My impression is that they are careful to educate their clients about confirmed subscription and, other measures which I don't remember. Perhaps, they even require prior notification when a bulk emailing is to take place.

Since many large emailers have taken preventative measures to ensure spam doesn't come from one of their clients or through open proxies or relays, spammers have increasing used trojanized machines and looked for servers to exploit. Perhaps one out of 20 enquiries here relates to security issues rather than someone who is sending bulk email to unconfirmed lists (innocently or on purpose). Open proxies or relays also show up occasionally - usually because of an error, not because the admin didn't know about securing them.

Other problems such as no rDNS (the lookup doesn't show the same address - again, I am not sure of the proper term), header lines so far off the standard that the spamcop parser can't read them, and still using the email 'bounces' (which even aol, I believe, has admitted is no longer a good idea), have also been discussed as resulting in being placed on blocklists (not all are spamcop's).

So the short answer is that most spam related instances of blocklisting are security or technically related which is why the posts assumed that - when actually it was a broken mirror that kept you from seeing the listing. Posters here still don't know what was the cause of the listing - though apparently you do.

Derek T. thought that spamtraps might become useless because of email bounces and autoresponses, but it seems to me that most of the posters who discover that's why they got blocklisted were not unhappy about turning those functions off or that the listing did point to an insecurity that they were glad to be able to find.

My contention is that spam continues to be a problem for legitimate users now because of incompetence and irresponsibility rather than malice. For the competent and responsible user or admin, any interruption of email service is temporary and shortlived caused by the inevitable errors that happen in any system. For the incompetent, irresponsible, and greedy, they would be permanently blocked by those who don't want spam. In that case, spamtraps would be useful to inform those who are merely ignorant of current procedures. (this last is not directed toward Oleg, but just an aside).

Miss Betsy

Link to comment
Share on other sites

Again, that sure looks like you were asking someone about something.

Not about administration, but about SMTP protocol principles.

Your client, only you would know if this is normal or not.

Nope. Only recipient of message can actually decide, is message from my client a spam or not. Not me, nor some other intermediate relay. Only recipient.

I have done and still do many things.  Your opinion falls into the debatable range.  Security is a major factor in the running of any e-mail system.  spam comes from both customers and interlopers, received by all, so I'm really not sure what point you're really trying to make.

15334[/snapback]

I just believe that spam from legitimate clients is very dufficult to control on intermediate relays. Definition of spam is different according to recipient, so only recipient can actually report about spam. Pricelist sent to subscriber isn't spam, but the same pricelist, but unexpected by recipient, is spam. Such things are just uncontrollable by intermediate relays.

Link to comment
Share on other sites

Not about administration, but about SMTP protocol principles.

Out of context .. you asked something, Miss Betsy gave it a shot, I responded to Miss Betsy, you stated that you made no query .... seems to be something lost in translation here.

Nope. Only recipient of message can actually decide, is message from my client a spam or not. Not me, nor some other intermediate relay. Only recipient.

Again, something lost here also ... you pointed at the scenario of your customer sending out 5,000 e-mails, asking if you should decide Was it "flood stage of the river" or simply distribution of new pricelists to pricelist subscribers ? ... and this was in reference to checking the various server logs for changes in traffic patterns. If your customer never did this before, that would be an issue. If this customer does this on a repeated basis, then that would be "normal" ... thus, the "only you can decide"

I just believe that spam from legitimate clients is very dufficult to control on intermediate relays. Definition of spam is different according to recipient, so only recipient can actually report about spam. Pricelist sent to subscriber isn't spam, but the same pricelist, but unexpected by recipient, is spam. Such things are just uncontrollable by intermediate relays.

I still don't know where you're trying to go .... in my case, sending spam is not something done by a "legitimate" client. At best, I'm thinking that you're trying to argue about/over both sides of the fence, but this Topic was started from an e-mail administrator point of view, trying to track down a spam issue ....

Link to comment
Share on other sites

Whether or not your clients use confirmed subscription (industry standard practice) is something that you can determine and require.

You can also limit the number of emails that go out (not necessarily the same for all clients).

It is the *sender* who controls whether spam is sent or not. Other mail admins have been able to use practices that make it difficult for spammers to use their networks.

As you point out, spam is about conSent, not conTent. From the sender end, that means confirming that the recipient wants the emails (pricelists) and sending emails frequently enough that the recipients don't forget, or if the recipient changes email addresses that the sender finds out before someone else gets it and reports the pricelist as spam since they never requested it. If the sender does all these things and a reporter says this is spam, they have evidence that it was a mistake. If not, then it is the sender's word against the recipient's word. And since the sender is the admin's client and the recipient is not, who do you think wins that one? Which is why recipients have started using blocklists to block IP addresses where spam is coming from.

There is no reason why a server admin cannot require the senders on his network to be responsible. There are enough legitimate bulk emailers who would like to be on a network that did not get blocked to make it worthwhile - and increasing end users who are not bulk emailers who don't want to use an email provider who does not do those things that make it very difficult for spammers to operate without resorting to trojans and exploits - and make it very difficult for them to do that also.

Miss Betsy

Link to comment
Share on other sites

It is the *sender* who controls whether spam is sent or not. Other mail admins have been able to use practices that make it difficult for spammers to use their networks.

Actually I would have to disagree with that statement.

SpamCop bl is based on user reports.

If enought users report a message as being spam, it will get an IP listed regardless of where the sender used a comfirmed opt in list or not.

Yes the sender would have proof that he did not send spam; but the receipents reporting it as spam makes it spam from a report point of view.

The dividing line can become very thin as to is a message spam or not, but it basicly comes down to

Only recipient of message can actually decide
If he thinks it is spam, then he needs to be removed from the list regardless of where it was a confirmed OPT in or not. I believe that is the point that OlegD is trying to make (though admittedly not his primary point)
Link to comment
Share on other sites

If enought users report a message as being spam, it will get an IP listed regardless of where the sender used a comfirmed opt in list or not.

Yes the sender would have proof that he did not send spam; but the receipents reporting it as spam makes it spam from a report point of view.

However,spamcop will delist immediately if shown proof that the list was confirmed subscription *and* fine or suspend the reporters. Spamcop does not consider emails to confirmed subscription lists to be spam - no matter whether the reporters forgot or were too lazy to unsubscribe and reported it because they were no longer interested.

emails can be considered spam only if they are unsolicited (unconsented to). Individuals can decide whether an unsolicited email is unwanted (for instance, the long lost cousin or an email from the friend of a friend who has what you told your friend you wanted to buy) and decide not to declare it spam by reporting or JHD.

The fine line is when you have given someone your email address. Most reputable online merchants have a way to subscribe or unsubscribe to future emails that do not involve the present transaction on the same page as where you enter your email address. IMHO, it is more effective if they don't unsubscribe or do send you email for you to handle it directly with them rather than report it as spam. Others disagree.

The dividing line is whether or not the email was confirmed subscription. If it is, it is not spam, no matter what the recipient says. If it is not, it is spam, whether or not it is reported.

Miss Betsy

Link to comment
Share on other sites

Again, something lost here also ... you pointed at the scenario of your customer sending out 5,000 e-mails, asking if you should decide Was it "flood stage of the river" or simply distribution of new pricelists to pricelist subscribers ? ... and this was in reference to checking the various server logs for changes in traffic patterns.  If your customer never did this before, that would be an issue.  If this customer does this on a repeated basis, then that would be "normal" ... thus, the "only you can decide"

This CAN be an issue. There is ONLY PROBABILITY of an issue. Probability isn't enough for blocking.

I still don't know where you're trying to go .... in my case, sending spam is not something done by a "legitimate" client.  At best, I'm thinking that you're trying to argue about/over both sides of the fence, but this Topic was started from an e-mail administrator point of view, trying to track down a spam issue ....

15341[/snapback]

Following is just my IMHO.

If legitimate client (not open relay, that not seems to be trojaned, no unusual traffic, didn't sent spam before) needs to send some amount of mail, it's OK. Then recipients of it's message can take a decision, was this spam or not (probably with help of SpamAssassin or something like). If this is spam - well, there is abuse[at] service, RIPE contacts, etc. Abuse, using the spam headers, identify and punish spammer. There is a normal scenario with responcible abuse service, and no probability there, only facts and assurance. So, if I am is representative of an abuse service, I need facts, not probabilities, to take a RIGHT decision about a RIGHT spammer, but not simply about client that sent most of all mail messages yesterday :-) Do you understand my point of view ?

Link to comment
Share on other sites

If enought users report a message as being spam, it will get an IP listed regardless of where the sender used a comfirmed opt in list or not.

Yes the sender would have prove that he did not send spam; but the receipents reporting it as spam makes it spam from a report point of view.

However,spamcop will delist immediately if shown proof that the list was confirmed subscription *and* fine or suspend the reporters. Spamcop does not consider emails to confirmed subscription lists to be spam - no matter whether the reporters forgot or were too lazy to unsubscribe and reported it because they were no longer interested.

I am afraid that you have missed my point and I believe one of OlegD's and that is the burden of proof lies with the sender, not the reporter.

SpamCop will accept a report and consider it as spam just because it was reported. Only after the sender has provided proof that it is not spam will SpamCop then change the definition of that piece of mail from spam to NonSpam, but in the mean time the recipient is punished by being block regardless of the face that he may or may not be guilty.

I am not saying that SpamCop must change its ways, but rather that we must be a bit more understanding of those who are attempting to prove they have not sent spam while being punished through blocking.

And as far as fines go, lets get real. How do you fine a free account, and how many fines have SpamCop actually collected, I would hazard to say that the number is extremely small.

In California you can get a ticket for driving above the speed limit. Yet it is safe to say that over 90% of the cars on the road do exceed the speed limit (unless traffic hinders them in doing so) with the vast majority of them never being sited. The law says exceed the speed limit, get a ticket, reality says its OK to exceed the speed limit 5 to 10 mph, just be careful how far you push it. The same is true for SpamCop.

The question is has SpamCop gone a bit too far in blocking too soon or on too few reports and without first sending out warnings? I do not know the answer. Just raising it as something to think about.

And before you wonder what side of the fence I am on, I appreciate and use SpamCop and believe that it provides a great service. But we need to be open to reason as well.

Also it would appear to me that OlegD's native language is not English and as such we should be careful not to take what is written too literally but to try to look for the intended message which at times is buried underneath misleading words due to a lack of familiarity with the language.

Link to comment
Share on other sites

I am afraid that you have missed my point and I believe one of OlegD's  and that is the burden of proof lies with the sender, not the reporter.

I just beleive that there must be provided some info about reasons of listing, so abuse service of listed mailserver will have evidences and facts to identify spammer (or security problem, or misconfiguration, etc) instead of guess-work.

Also it would appear to me that OlegD's native language is not English and as such we should be careful not to take what is written too literally but to try to look for the intended message which at times is buried underneath misleading words due to a lack of familiarity with the language.

15371[/snapback]

Yes, you are right :-) I'm sorry for my English.

Link to comment
Share on other sites

This CAN be an issue. There is ONLY PROBABILITY of an issue. Probability isn't enough for blocking.

Following is just my IMHO.

If legitimate client (not open relay, that not seems to be trojaned, no unusual traffic, didn't sent spam before) needs to send some amount of mail, it's OK. Then recipients of it's message can take a decision, was this spam or not (probably with help of SpamAssassin or something like). If this is spam - well, there is abuse[at] service, RIPE contacts, etc. Abuse, using the spam headers, identify and punish spammer. There is a normal scenario with responcible abuse service, and no probability there, only facts and assurance. So, if I am is representative of an abuse service, I need facts, not probabilities, to take a RIGHT decision about a RIGHT spammer, but not simply about client that sent most of all mail messages yesterday :-) Do you understand my point of view ?

15369[/snapback]

I don't think anyone was reccommending you implement a full block on questionable changes in activity. There are options like throttling the flow and actually monitoring the content of the mesages to check for obvious spam like content. Configurations change. Relays are opened by accident, buggy scripts are put in place, etc.

I think you are being very responsible in your conduct both for you customers and the internet as a whole. I think we are just trying to suggest ways to protect the internet even more while not infringing greatly on your customers. Having a large run of email take twice as long won't hurt, especially if you inform your customers this will happen.

just beleive that there must be provided some info about reasons of listing, so abuse service of listed mailserver will have evidences and facts to identify spammer (or security problem, or misconfiguration, etc) instead of guess-work.

That information is always available from deputies<at>spamcop.net

Link to comment
Share on other sites

just beleive that there must be provided some info about reasons of listing, so abuse service of listed mailserver will have evidences and facts to identify spammer (or security problem, or misconfiguration, etc) instead of guess-work.

That information is always available from deputies<at>spamcop.net

This post has been edited by StevenUnderwood: Today, 05:29 AM

I would tend to restate that as "That information is only available from deputies<at>spamcop.net" They seem to be a bit tight with how much information they are willing to release.
Link to comment
Share on other sites

They seem to be a bit tight with how much information they are willing to release.

With the spamtrap data, that is very true and I agree with that tactic. They also have access to ALL the regular reports against an IP and if you can prove your relationship to the IP in question, should have no problem getting that type of information.

I think the fact that spam has been received by a spamtrap from your address should make you question everything about your setup. The deputies do not seem to mind telling you what type of path it came through. I have seen them call out a virus on the network, virus or spam bounces, an actual spammer on the network and of course the SMTP/Auth hack.

Link to comment
Share on other sites

I think most posters realized that Oleg's native language was not English and therefore did not start accusing him of being a spammer even though it sounded as though he were defending spammers.

Server admins *are* the judges of what is spam and the ones who have to decide, not only whether an email is spam, but what to do with the spammer's account.

One of the biggest criticisms of the spamcop blocklist (and why many admins will not use it to block email) are the reporter errors. I think the algorithym has been changed so that to prevent listing because of errors (the more than one reporter). And the fines, I think, are deducted from one's fuel. Even seasoned reporters will make a mistake so that, I think, that experience and record of errors are taken into account. Like the server admins, spamcop deputies have to judge whether this was malicious, an error from inexperience, a rare slip, or an incredibly stupid reporter. I expect for free accounts, it is warnings or suspension.

And I expect for server admins, the same kind of criteria apply when they get a report and look at the email and the client's history. That's why if I were an admin, I would have some way of knowing beforehand whether the client had accepted mailing practices in place. For those admins who have many clients, spamcop reports are a high priority - to either catch a spammer or to contact spamcop about an error so that they are not listed. And, as I said, there is no confusion about confirmed subscription from the server admins point of view: if it is confirmed subscription, the reporter is in error (though there have been cases where the unsubscribe got broken); if it is not confirmed subscription, then it is spam and he must do whatever his spam policy is.

Unfortunately, there are no reports with spamtraps. I still think there must be some way that spamcop can work with whitehat admins to make it easier for them, but that would certainly require more money (for more personnel).

Other blocklists are more carefully screened and don't have as many errors as spamcop. OTOH, they are much more difficult to be removed from. Taking one thing with another, if I were an admin, I would prefer spamcop even if I had to deal with reporter errors. And I would pay the SORBS fine (my ISP didn't pay it until they got a complaint from a customer which is an ok policy with me). If life were perfect, there would be no spammers to start with. One cannot realistically expect the solutions to spam to be perfect. We don't expect that from other areas of life - we just expect some inconvenience and workarounds.

Miss Betsy

Link to comment
Share on other sites

<snip>

And as far as fines go, lets get real.  How do you fine a free account,

<snip>

...To be fair, no one said that a fine was the only possible penalty. Free account users can be suspended.

The question is has SpamCop gone a bit too far in blocking too soon or on too few reports and without first sending out warnings?  I do not know the answer.  Just raising it as something to think about.

And before you wonder what side of the fence I am on, I appreciate and use SpamCop and believe that it provides a great service. But we need to be open to reason as well.

<snip>

15371[/snapback]

...Since SpamCop doesn't block anything, I assume you meant "add to the blocklist." If so, then any such adding too soon (and, remember, the formula that triggers blocking takes into account many factors, not just user reports) is offset by its quick (and free!) de-listing feature. :) <g>
Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...