Tag Info

Hot answers tagged

94

It is the nature of SMTP (the protocol used to transfer mail) that no validation is done on the sender address listed in an email. If you want to send an email that appears to come from president@whitehouse.gov...you can go ahead and do that, and in many cases there's nothing anyone can do to stop you. Having said that, if you establish SPF records for ...


91

Since it hasn't been explicitly stated yet, I'll state it. No one's using your domain to send spam. They're using spoofed sender data to generate an email that looks like it's from your domain. It's about as easy as putting a fake return address on a piece of postal mail, so no, there's really no way to stop it. SPF (as suggested) can make it easier for ...


43

I last looked at this quantitatively in July of this year (2012). In July, my mailserver received about 46,000 attempts to deliver mail; of those, about 1,750 returned and were permitted through by the greylisting (and passed valid sender domain, SPF and some other non-content-based tests). Of those, about another 1,500 were filtered by my content-based ...


29

I endorse the answers already given regarding SPF (+1, each of you!) but please note that if you decide to go this way - and it's a good way - there is no point in doing it unless you identify and advertise all hosts that are approved to send email for your domain, and hard-disallow all others with -all. Not only will ?all and ~all not have the desired ...


21

The fact that someone can send you mail addressed to your own mail server's IP address has absolutely no bearing on whether the mail server is an open relay. Open relays accept mail for any and all systems outside their administrative domain and forward them onward. This clearly is not what's demonstrated here. Ask the security firm to share whatever it is ...


20

Sender Policy Framework (SPF) can help. It is an email validation system designed to prevent email spam by verifying sender IP addresses. SPF allows administrators to specify which hosts are allowed to send mail from a given domain by creating a specific SPF record (or TXT record) in the Domain Name System (DNS). Mail exchangers use the DNS to check that ...


20

From your error log they are sending a HTTP/1.1 request without the Host: portion of the request. From what I read, Apache replies with a 400 (bad request) error to this request, before handing over to mod_security. So, it doesn't look like your rules will be processed. (Apache dealing with it before requiring to hand over to mod_security) Try yourself: ...


15

I'm looking forward to seeing other answers to this question, but my feeling is that if you're catching compromised mail accounts after only 40 spams have got through, you're doing really well. I'm not sure I could detect similar abuse so quickly, and the prospect worries me. But I'm appalled that seven sets of credentials were stolen in the past week ...


9

A word of warning: An MX record provides information about where email should be delivered. It does not necessarily provide any information about where email originates. It is entirely possible -- even likely -- that mail will be coming from a system that is not listed as an MX for the given domain. SPF records, on the other hand, allow you to verify ...


8

Filtering IPs is not a good idea, imho. Why don't try filtering the string you know? I mean: iptables -I INPUT -p tcp --dport 80 -m string --to 60 --algo bm --string 'GET /w00tw00t' -j DROP


7

Iv also started seeing these types of messages in my log files. One way to prevent these types of attacks is to setup fail2ban( http://www.fail2ban.org/ ) and setup specific filters to black list these ip address in your iptables rules. Heres a example of a filter that would block the ip address associated with making those messages [Tue Aug 16 02:35:23 ...


7

There is no easy way to check. The best thing you can do is use CAPTCHA to verify that it is a real human registering. You could also keep your own list of not allowed emails for any users that are abusing your site. You could then ban those emails from being used to register / login on your site.


7

The easiest approach would be to time limit the blacklisting. The first time an IP is put into the DB, set the timeout for 3 days or something. On subequent submissions from that IP: The second time junk comes from an IP set the timeout for 2 weeks. The third time junk comes from that same IP set the timeout for Permanent (0) Or something similar to that, ...


7

spambots usually still don't do message queueing , but some of them just send the spam twice to every recipient with a few minutes delay to defeat greylisting. also, nowadays, spam from spambots isn't the real problem anymore, spam from compromised yahoo accounts etc is much harder to catch. From that point of view, greylisting is not as effective as it ...


6

The IP addresses 10.0.0.0 to 10.255.255.255 are reserved for private networks, i.e. the traffic you see is coming somewhere from your internal network, so try to figure out which machines those are, or contact your hosting provider and have them poke around what their 10.10.0.3 machine is doing.


6

We mitigated the same issue by using an outside vendor as our e-mail gateway (in our case, Exchange Online Protection but there's many other comparable services). We then configured all our e-mail sending services to use that as the smarthost. Now, all our outgoing messages are associated with the reputation of the external e-mail gateway. Because of that, ...


6

Since nobody else has mentioned it yet, this is one of the problems SPF was designed to fix. If you publish a correct SPF record in your DNS and have your server check SPF records, it would know that outside servers are not allowed to send e-mail with "From: *@yourdomain.com". As a bonus, this not only fixes your immediate problem but will also block spam, ...


5

It doesn't look like a SPF would have helped in this particular example. A machine that was bothering to check SPF records to reject mail is unlikely to be so broken as to accept mail for a nonexistent domain, then decide it can't deliver it and generate the bounce message. If mail-gw01.fsdata.se, the machine accepting mail for whao.se, had bounced it ...


5

According to DreamHost, your VPS comes with full root access. That means you can set up your own mail transfer agent (MTA), instead of using their preconfigured one. For example, you could use the MTA Postfix and one or two good real-time blacklists (e.g., Spamhaus and UCEPROTECT). THis is what I do, and the results are much better than any preconfigured ...


5

As silverfire indicates, it depends on two things: How many emails are we talking in terms of numbers (10,000 or 100 a day?) How much bandwidth you have connected to your mail server The only thing you can do to reduce your bandwidth is to use an external spam filter, such as Postini (which is a Google service, who we have had success with for some of ...


4

w00tw00t.at.blackhats.romanian.anti-sec is a hacking attempt and uses spoof IP's so lookups such as VisualRoute will report China,Poland,Denmark etc according to the IP being seconded at that time. So setting up a Deny IP or resolvable Host Name is well nigh impossible as it will change within an hour.


3

In response to the other answers here: It could also be forged IP headers. Ask your ISP to do a proper job (ie, block spoofed IP's).


3

I would recommend using Google Apps. The standard edition is free for up to 50 users, or you can go for the premier version which has very advanced Postini spam protection.


3

You can't do that, you can only play by the rules and hope for the best. You are only as legitimate as your administration techniques over time demonstrate you to be. Some things you can do to get started are have your users to add you to their address books and don't break any usage policies or industry accepted behavior guidelines. If an individual ...


3

If you are doing everything right, you should have few problems. The more things you do right the more likely you won't get flagged as spam. There are a few sites that will evaluate your mail server to verify your configuration is correct. I have noticed a lot of automated systems don't use their FQDN in their HELO command. This makes you appear more ...


3

You can't figure out where those servers are on the Internet because that's an internal Intranet IP address. Whoever is spamming you is apparently on the same network as you. You might want to look into that.


3

Also consider you can host SMTP servers in one or more datacentres then relay back to your servers in house. As per Mark's answer, Postini would be more cost effective form of this arrangement.


3

It's unclear to me what you're seeing. I'd turn on "Message Tracking" in Exchange if it's not already enabled (see http://support.microsoft.com/kb/246856) and verify that the Exchange Server is or isn't the source of the messages. I'd stick a rule in the edge firewall to deny outbound connections on TCP port 25 except from the Exchange Server computer. ...


3

You could configure your spam filtering software to verify SPF records -- This does what you're asking, but in a slightly more intelligent way. Denying mail because the sending server is not listed in the SPF record for a domain doesn't really make sense though -- Many residential ISPs block access to all but their mail server, which means that you may ...


3

DNS is broken. 108.163.232.130 reverses to s1.om-p.com which doesn't resolve.



Only top voted, non community-wiki answers of a minimum length are eligible