Email Error .. my ip public blocked
-
@JaredBusch said:
Because the first is you simply taking my word for it and blocking an IP. The second is adding a (possibly faked email) to an existing database of emails that does not just block for a single thing. it uses an algorithm to set the scores.
But not for the IP address right? Presumably we all have an endless supply of spam. yes that is an assumption but I'm confident that this is reasonably true. Given that we have an endless supply of example spam to work with, the IP address portion is and always has been "taking their word for it" in cases of submissions. Am I missing some component here where I don't just choose the IP address to submit (if I want to?)
-
I totally get that one takes a little more work and isn't as easy as a "block this ip please" form. But given the boilerplate component there is still just an IP field to modify as desired.
Although I do believe that there used to be pure IP address fields to fill out long ago. Good that that has changed (from what I can tell) but it doesn't appear that the effort to block someone arbitrarily is any harder than it used to be, only submitting at all is a tiny big harder.
-
Now what does improve this situation some is that it appears that most blacklists require paid membership in order to be able to submit. At least the ones that I have investigated. So regularly doing this to people seems like it might cause issues with your account, at the very least. Or so one would hope.
-
I assume that submissions work like '1000 people submit spam example = this is spam' but '1 person submits spam example = this is not spam'. So assuming you don't have 1000 competitors all colluding to screw you you should be ok.
-
@Carnival-Boy said:
I assume that submissions work like '1000 people submit spam example = this is spam' but '1 person submits spam example = this is not spam'. So assuming you don't have 1000 competitors all colluding to screw you you should be ok.
Today I believe that that is likely true, but leaves open the potential (no idea how they protect against this) of someone sending out spam as if they were you to generate the 1K examples.
Long ago I'm pretty sure it did not work that way. Getting blocked from time to time used to be pretty common. This is pre-2003, I would say.
-
@scottalanmiller said:
@Carnival-Boy said:
I assume that submissions work like '1000 people submit spam example = this is spam' but '1 person submits spam example = this is not spam'. So assuming you don't have 1000 competitors all colluding to screw you you should be ok.
Today I believe that that is likely true, but leaves open the potential (no idea how they protect against this) of someone sending out spam as if they were you to generate the 1K examples.
Long ago I'm pretty sure it did not work that way. Getting blocked from time to time used to be pretty common. This is pre-2003, I would say.
I agree, back then it was more common - hell it happened at the fortune 500 company I worked for... so sure, it happened a lot more.. clearly they've changed the way it works, it's really not a problem these days unless you really are a spammer or your network is infected and being used as one.
-
It's been a long time since I had to deal with it, but a lot of other things have changed too since them (SPF, PTR, etc.)
-
@scottalanmiller said:
@Carnival-Boy said:
@scottalanmiller said:
- Lack of knowledge of email systems (or else they would be hosted) leading to more issues below
Wait, are you saying that anyone who runs on-premise e-mail is an idiot?
That's not what I said. If you read the lead in to the list, I pointed out that these things were things that typically or generally happened with on premises systems. So "anyone" doesn't apply here. And not being an email specialist is in no way the same thing as an idiot, so the idiot bit does not apply.
OK, let me re-phrase, are you saying that anyone who has decent knowledge of e-mail systems but is running on-premise is an idiot?
@scottalanmiller said:
Those that want the "feel" of self hosting email do so by running Exchange in house but having a mailbagger running in the hosted space as the real email server (MXLogic, Postini and similar services.) They are the actual email servers and so the email is hosted, the mailboxes are the only part that are local (which are post-email services, excuse the pun.)
I don't believe on-premise Exchange is "hosted e-mail" just because you use Postini or another filtering service on the front-end. Apart from anything, I suspect that for most companies internal e-mail far outweighs external e-mail, so the majority of e-mail won't even hit Postini.
-
@Carnival-Boy said:
I don't believe on-premise Exchange is "hosted e-mail" just because you use Postini or another filtering service on the front-end. Apart from anything, I suspect that for most companies internal e-mail far outweighs external e-mail, so the majority of e-mail won't even hit Postini.
In a major way (and all technical ways) it actually is. Email is defined by the use of the SMTP protocol. When you use Postini or similar, all of the SMTP handling in some cases or at least all of the public SMTP handling actually is hosted. The email portion becomes completely hosted. The part that remains on site is the mailboxes, POP3, IMPA4 and similar protocol handling and storage. Technically, at that point, it's not email anymore but a fileserver portion.
In the old days we didn't have these components. There was still storage, obviously, but there were no protocols for it and such. With Postini, there is all the traditional storage that is hosted and all of the SMTP email handling (assuming you have both inbound and outbound configured.) The only thing that is happening with the local system is the file serving and interface handling for the local users. And in some cases, not even all of that (around retention systems, typically.)
-
Technically, when you send an "email" from one person to another on the same system it's not exactly email. We all call it that because we are all sharing one interface. But we aren't using SMTP, we are actually using a local specialized file server. At no point does the email get "sent" anywhere, which is what makes it email. The whole SMTP layer is skipped.
It's two separate systems. The old email SMTP system remains, but the mailbox to mailbox stuff does utilize that system, isn't required to exist for email to work and is a completely new system added on behind email systems.
-
A similar example that is equally confusing is VoIP telephony. Are we making a "phone call" when we don't use the phone system? We don't normally consider talking on Skype, Whats App, Google Talk, XBOX 360 games, Google Hangouts and similar to be phone calls. At least most people do not - because they don't use a phone number or go to the phone system and can't reach "phones." Cell phones are different because they always (AFAIK) use a phone number and can call the phone system, PSTN. Most people define phone calls as those that traverse the PSTN and can call.. phones. A little bit of a grey area here.
In the case of a VoIP PBX then, are you making a phone call when calling extension to extension? Legally, no. Technically you are doing audio communications but not via what is accepted as the telephone. It is no different than Skype or Google Hangouts. You don't hit the PSTN or use the telephone protocols. Wikipedia doesn't define telephone in this way, but their definition covers things like cans with string attached, so probably isn't a good example. They rely on a longer description that seems to agree with the above.
The point being that in the case of email or phones, the "email or phone" portion is normally hosted and then additional "local" functionality may be hosted (Office 365 or RingCentral) or may be local (on premises Exchange or a ShoreTel PBX.) But the additional portion is behind the email or phone components and relies on the actual email handling or the actual telephony handling to be hosted.
-
@Carnival-Boy said:
Apart from anything, I suspect that for most companies internal e-mail far outweighs external e-mail, so the majority of e-mail won't even hit Postini.
I've often used this as a "typical" use case differentiation between small and large companies. Small companies typically send the majority of their "email" to external entities. Large companies typically send the majority of their email internally. Once you hit a few hundred users, email becomes heavily internal in nearly all cases, that's definitely true.
But legal restrictions on email, for example, don't normally apply when email is not made public or communicating via SMTP. For example, HIPAA regulations on email don't apply if SMTP connectors aren't enabled. It is only once SMTP handling is added that Exchange turns from a mailbox server into an email server. Using it without SMTP would classify it only as a unique fileserver rather than an email server. Once SMTP is on, it is both. But the features that make Exchange popular compared to Postfix or Sendmail, are all in the "fileserver" and interface portions, not in the email portions.
So it becomes complex. Email definitions are definitely not hard and fast. By the definition that all electronic communications is email (which means text messaging and instant messaging are email, which isn't a very useful definition) then definitely local mailbox handling is email. If you use the definition for network email (also from Wikipedia) that states that email is transferred via FTP prior to 1982 and SMTP port 1982, then we have something more solid for describing email in general and mailbox to mailbox handling of systems like Exchange and Cyrus becomes non-email.
-
@Carnival-Boy said:
OK, let me re-phrase, are you saying that anyone who has decent knowledge of e-mail systems but is running on-premise is an idiot?
Of course not, but the likelihood of people who know email well running on premises becomes lower while the chances of people who don't understand it well or who can't convey this information well to management well having on premises is higher. The numbers shift. As it is generally valuable to be hosted it just makes sense that those who know email best will push in that direction more often than not and those that have clout or can convey these reasons to management will generally be more successful in that endeavor. There are good cases for being on premises with email (or mailboxes far more often) but they are declining over time and are relatively rare, probably below 10% (total guesstimate) of the sub-enterprise market and probably around 50% (or lower) of the enterprise market.
-
For those of us who have built email system from components (I can't recommend against this enough for use, but for learning about email, it is pretty useful) you actually have to assemble the email handling MTA (Sendmail, Postfix, Qmail, etc.) and the mailbox handler (Cyrus) and a web interface (assuming you want one, like IMP) and other items like SPAM and AV filtering. When you build email systems like this it is very interesting to see how they work together. Exchange and Zimbra are the same, just these components are all managed for you and you "never" see them separately or put them together manually and see how they are talking from one to another (technically sometimes when you get big you will pull Exchange apart and do this or pull Zimbra apart and do this.)
The SMTP email portion can be kept on a different server than the mailboxes, for example. You can send and receive email with nothing but Postfix (what I prefer to use.) This is the email system. Once Postfix has done its job it is able to hand off files to something like Cyrus which is a file server that can share out files that it manages (Cyrus works with files, not with SMTP) via protocols like POP3 and IMAP4 which we often loosely call email protocols but are actually mailbox (fileserver) protocols. You can expose this even more by attaching directly to the system at the CLI and accessing the files stored there with no network at all and see that nothing like SMTP is in play. Or you can view them, using something like IMP, over HTTP, another fileserver (web) protocol.
This combination of uses helps to explain where the network email (SMTP) portions are delineated in the system and where fileserver (mailbox) portions live and why I view having SMTP handling hosted as having the email hosted in a way because the sending and receiving of email (the post office portion, if you will) is hosted and only storage of the then received email (the sorting box on your desk in your office, if you will) might remain on premises.
-
wow, I'd love to see how this stands up in court... someone requests all email communication and you only supply things that traversed SMTP, and claim the rest aren't email... we'd see a new law come in pretty fast.
-
@Dashrender said:
wow, I'd love to see how this stands up in court... someone requests all email communication and you only supply things that traversed SMTP, and claim the rest aren't email... we'd see a new law come in pretty fast.
I don't believe that they normally request email, that's just how the media reports things - modified for non-technical people. Legally if they request email it would have to fall to one of the two definitions, one meaning all communications including text, instant messenger or whatever or the other being SMTP. And since no one actually treats it as the former, it's pretty darn safe to assume that it is the later. Which is why legal hold systems often exclusively grab the SMTP traffic for legal holds, because only that is email.
-
Remember that "requesting email" is a completely illogical thing to do in a court if the goal was to see what had been said. Why would any court say "Show us all of the email communications that went through Exchange but don't show us the Lync messages, documents stored in other systems, contents of attachments, etc."
Of course they don't do that. That would be incredibly silly. They request categories like "all external communications", "all internal" or whatever it is they are looking for.
