I have a mailserver with exim4 and spamassassin installed.
We have a problem of (internal) spam to a large number of mailinglists, coming from a few users (which we cannot just educate or block for multiple reasons)
Is there a way to block emails to which an unreasonable amount go to the same domain (e.g. 10) to force these users to BCC?
Yes, you can do this in SpamAssassin. I'm not as much an exim expert, but iirc exim can do this as well (though it may have a hard recipient limitation that is agnostic to To/Cc vs Bcc).
This should do it:
header DTECH_TEN_TOCC_IN_SAME_DOM ToCc =~ /(\#[^,>;]{3,99}[a-z]\b)(?:[^\#.-][^\#]{0,99}\1){10}(?![.-])/
describe DTECH_TEN_TOCC_IN_SAME_DOM Ten consecutive recipients have the same domain
As I've written it, this only catches ten consecutive recipients with the same domain, which must all be in the same header (ToCc means either To xor Cc; it does not merge the headers). If you change the third character class from [^\#]{0,99} to .{0,999} to match any character over a longer period of time, the rule will be good for more than just consecutively listed addresses, but note that this would make the regex far more expensive to compute.
You also have to make sure that SpamAssassin is looking at your internal and outbound mail, which is nonstandard. Finally, you'll have to score the rule. Please test copiously before you do that. Especially since this is not a spam rule (it will hit more non-spam than spam; consider a similar rule with testing stats: __TO_MANY).
You will not, however, be able to tell users why the message was rejected. An SMTP reject (e.g. from Exim) can have a custom "why this was rejected" prompt, which is highly useful for policing attachment sizes or even informing users that they're sending too much mail (perhaps they are infected). You can configure Exim to run SA at SMTP time (e.g. sa-exim), but then every spam rejection would have the same message to the end user. The other option would be to accept the message and then bounce it back, including the SpamAssassin rule hits. Be very very careful with that approach as it often leads to backscatter.
Related
I am wondering how, on a technical level, IPv4s and domains can be distinguished.
An IPv4 takes the form [0-255].[0-255].[0-255].[0-255].
A domain takes the form (a)+.b, where (a)+ denotes that this string occurs at least once and may repeat.
The values of a can be considered arbitrary alphanumericals (so yeah, mathematically, I am not super correct with the expression above), as can the values of b, though b has practically more restrictions because it must usually be registerd Top Level Domain (TLD), but apart from that, may be arbitrary alphanumericals, either.
In theory, the set of ip addresses looks like a subset of the set of domain addresses.
Edge cases like special characters and special addresses are not relevant for this question and can be ignored.
When I enter an IP or domain into my browser address field, the terminal, or an application, how does the system know whether I entered a domain that requires resolution, or an IP address that can be directly contacted?
Can someone, on a technical level, explain how the system handles these strings and what possible interactions can occur and whether (and why) this raises security issues, or not?
I was wondering, whether an attacker would be able to exploit this ambiguity and whether there are cases where exactly this already happened in the past.
I am wanting to block every country EXCEPT USA,Mexico, and Canada from my ecommerce site. From the research I have done, using an HTTPModule would appear to be the best method. However, this would require me going through a list of hundreds of ip ranges and woudl require quite a bit of code
Anyone have nay ideas on a quick way to do this?
Even if you did block IP address range this would change as the get reallocated or taken up. Also its possible to use a number of services to spoof IP addresses or even to go out through routers / gateways in other countries even if you're not in the places you want.
You could try looking at the locale and / or time-zones set on the client machines. whilst this is not infallible and can be worked around (if the client knows what you're doing to block them),
They are en-us, en-ca, fr-ca, es-MX, it's the letters after the dash that you want, which are the ISO 3166 Codes for Countries. This may give you a start, it's not a infallible, but you're not going to get that anyway, but its a very light weight way of removing a fair amount of visitors.
IMHO, the best approach: application and/or network firewall (appliance) rules (having said that, if you have one, this may even negate the need to do IP address filtering entirely)
IIS
My production server recently got a slew of access probes (to try and find a point to break in, to URI's like to /admin.php, /administrator, /wp-login.php, etc.), and I noticed that some of the REMOTE_ADDR's reported by Apache (IP4's) had two dots where there should be one.
What's up with this? Is this some way for servers to hide?
For one, it means that I need to log these to a wider field than expected. Expected would be xxx.xxx.xxx.xxx or 15 characters, but this might make it 16 or even 19.
[Edit: or better yet 50, see this]
The problem is happening in some code somewhere in your application (etc) that is doing formatting.
IP addresses are actually an array of 4 unsigned bytes. They are conventionally represented character-wise (for human consumption) in "ddd.ddd.ddd.ddd" form, but that is not the fundamental representation. The fundamental representation does not have dots in it at all.
It therefore follows that the extra dots you are seeing are some problem with either the way the IP addresses are converted to strings, or the resulting strings are incorporated into messages, or those messages are handled and ultimately displayed. The extra dots do not "mean" anything ... except ... possibly ... to say that some characters have been left out.
Without more information, we can't tell you where those dots come from, or how to stop them.
What's up with this? Is this some way for servers to hide?
Nope.
At the point that your systems first see those IP addresses, they are in 4-byte form, just like other IP addresses. The dots are not a new way to hide. Rather they are just a result of a local problem in the way things are being logged.
UPDATE
Looking at the evidence in your "half answer", one possibility is that you have some progress monitoring or debugging code somewhere that occasionally outputs a "dot" into the output stream. It looks like it would be on a different thread ...
So far my hosting company says only that I can clean up these values.
They are right. But you probably want to find where your application is injecting the garbage and fix that ... rather than massaging the log files.
What are you doing with that variable in your code? I expect it's being translated or parsed in some way that's adding the extra period.
It's extremely unlikely that Apache would report it that way, as that would be invalid as an IPv4 address.
Compare your output with the web server's access logs, which will have recorded the remote IP as Apache saw it.
Half of the answer is that php's $_SERVER['REMOTE_ADDR'] is untrusted because it comes directly from the http request as provided by the server to php it can apparently and from other reports be spoofed.
EDIT2: I have more recently found two more bad variables from $_SERVER with double dots, as follows:
SERVER_ADDR REMOTE_ADDR REQUEST_TIME_FLOAT
184..154.227.128 183.60.244.30 1391788916.198
184.154..227.128 183.60.244.37 1391788913.537
184.154..227.128 183.60.244.37 1391788914.368
184.154..227.128 184.154.227.128 1391086482.1889
184.154.227.128 183..60.244.30 1391788914.1494
184.154.227.128 183..60.244.37 1391788913.0523
184.154.227.128 183.60..244.37 1391788911.5938
184.154.227.128 183.60..244.37 1391788914.3977
184.154.227.128 183.60.244.37 1391788911..9855
So far my hosting company says only that I can clean up these values. That is easy, but cleaning up garbage is still garbage. If dots can and are being added, then the numbers can and possibly are be changed too I think. Humm?
See: this comment from the php manual.
Now that leaves the question where to find a trusted IP from the accessing client? Apache has it I'm guessing from the incoming http packet exchange with the client. (I'll ask this Q: in StackOverflow).
I want that my MC52i auto accept an incoming call. If I use AT commands to answer manually (ATA) it works fine, but I'm not able to force the modem auto accepting an incoming call. On other devices it works with ATS0=1 but not on the MC52i. I think it has something to do with the GPRS Mode?
What type of call are you trying to accept, voice or CSD? Setting S0 ought to be enough for this. Try to enable AT+CRC=1 and examine the +CRING: <type> unsolicited result code (see 27.007 for details). Does it fail to auto answer all incoming calls? Try to have it auto answer both voice calls and data calls. Try to call from PSTN, ISDN and mobile phone (both same operator and different operator. Try several different phone models). If it fails to answer all those cases then you probably have to write off auto answer as a possibility. Oh, by the way, also try with several different sim cards (from at least more than one operator) in the modem to rule out problems with the operator/subscription.
I have probably given enough options to tweak so that testing every single combination is not feasible and useful, but pick some variations of all of them and set up at least 20 different test cases.
Although very unlikely, I'll mention the following for completeness and as a background to one of the many reasons why testing with several different operators is important:
There could be a problem if the network does not include call type information in the Bearer Capability in the SETUP message and then the phone does not know how to answer the call. This is very unlikely today, but several years ago some network could behave so. Because of this the phones used to have a "receive next call as" configuration to determine how to behave then. But I assume all newer phones to just ignore this scenario (It was applicable back in the days when Ericsson made mobile phones in their own brand, at least I remember seeing seeing this configuration option in their single menu style phones like T28. I do not remember if it survived the conversion to the icon based menus).
I'm wondering how the browser, and/or DNS, handles a user entering an invalid character in a domain name.
Let's say that I own meat&potatoes, a well-known chain of fine dining restaurants. All of our marketing refers to us as meat&potatoes (meat + ampersand + potatoes, no spaces), and it's likely that fairly often, people are typing www.meat&potatoes.com into their browser.
How does the browser, and/or their ISP's DNS, handle this request? Are there any ways I can get the user to the correct domain without requiring them to make additional clicks / keystrokes?
Edit: In my limited testing, I've found that Chrome transforms the character into a URL-encoded version (e.g. %26 for &), and then sends a request somewhere that results in my ISP(RCN) giving me a search results page (because RCN is evil like that): www17.searchresults.rcn.com/… So, something is reaching the ISP.
Host names are limited (RFC1034 section 3.5) to letters (a-z), numbers (0-9) and hyphen (-).
Additionally, international characters are allowed by recent browsers using puny-encoding (RFC3492) - which basically applies to character values above 127.
I don't know specifically how browsers handle this, but I expect that they go by these two sets of rules, and gives the end-user an error/redirect for anything else.
And therefore it never gets as far as DNS / ISPs.
Unfortunately this means that there is currently no way to make "&" in a domain name work...