We have a server with DirectAdmin panel where is exim. It's default configuration like here:
http://files.directadmin.com/services/exim.conf
We get e-mails for example from kontakt#hoseo.pl to kontakt#hoseo.pl it's spoofed:
Examples:
1.
Return-path: <nickedc#gmail.com>
Envelope-to: kontakt#hoseo.pl
Delivery-date: Thu, 12 Sep 2013 03:15:21 +0200
Received: from [200.10.67.162] (helo=gmail.com)
by omega.hoseo.pl with esmtp (Exim 4.80.1)
(envelope-from <nickedc#gmail.com>)
id 1VJvV7-0003OM-UP
for kontakt#hoseo.pl; Thu, 12 Sep 2013 03:15:21 +0200
Received: from [191.7.129.87] (account quadrennial16#gmail.com HELO lyjqnysvr.nfevzzqxeweo.tv)
by (CommuniGate Pro SMTP 5.2.3)
with ESMTPA id 125612437 for kontakt#hoseo.pl; Wed, 11 Sep 2013 20:17:47 -0500
Date: Wed, 11 Sep 2013 20:17:47 -0500
From: <kontakt#hoseo.pl>
X-Mailer: The Bat! (v3.5.25) Home
X-Priority: 3 (Normal)
Message-ID: <9925188213.R1G0JAD6616751#hfvnvpdpni.dahsrtr.ru>
To: <kontakt#hoseo.pl>
Subject: Jestem gotow placic Ci 95 euro za spolecznie uzyteczne prace wykonywane w wolnym czasie
MIME-Version: 1.0
Content-Type: text/html;
charset=iso-8859-2
Content-Transfer-Encoding: 7bit
X-Antivirus: avast! (VPS 130911-1, 2013-09-11), Inbound message
X-Antivirus-Status: Clean
2.
Return-path: <dishwashersd333#google.com>
Envelope-to: kontakt#hoseo.pl
Delivery-date: Thu, 12 Sep 2013 02:14:09 +0200
Received: from [190.235.181.209]
by omega.hoseo.pl with esmtp (Exim 4.80.1)
(envelope-from <dishwashersd333#google.com>)
id 1VJuXw-004BKW-NW
for kontakt#hoseo.pl; Thu, 12 Sep 2013 02:14:09 +0200
Received: from [113.131.148.117] (helo=zczdtmhvqilhrkl.tnksjy.ru)
by with esmtpa (Exim 4.69)
(envelope-from )
id 1MMSEG-7581uu-1R
for kontakt#hoseo.pl; Thu, 12 Sep 2013 12:13:24 +1200
Date: Thu, 12 Sep 2013 12:13:24 +1200
From: <kontakt#hoseo.pl>
X-Mailer: The Bat! (v3.5) Educational
X-Priority: 3 (Normal)
Message-ID: <5655874272.ZBYQ02EL661445#ukcchbjmedjown.tboxgld.tv>
To: <kontakt#hoseo.pl>
Subject: Czy chcialbys (chcialabys) pomagac chorym w wolnym czasie i zarabiac minimum 300 euro w tygodniu?
MIME-Version: 1.0
Content-Type: text/html;
charset=Windows-1252
Content-Transfer-Encoding: 7bit
X-Antivirus: avast! (VPS 130911-1, 2013-09-11), Inbound message
X-Antivirus-Status: Clean
3.
Return-path: <walesg61#gmail.com>
Envelope-to: kontakt#hoseo.pl
Delivery-date: Thu, 12 Sep 2013 00:07:26 +0200
Received: from [181.67.29.61] (helo=gmail.com)
by omega.hoseo.pl with esmtp (Exim 4.80.1)
(envelope-from <walesg61#gmail.com>)
id 1VJsZJ-003a4R-Rp
for kontakt#hoseo.pl; Thu, 12 Sep 2013 00:07:26 +0200
Date: Wed, 11 Sep 2013 23:09:57 +0100
From: <kontakt#hoseo.pl>
To: <kontakt#hoseo.pl>
Subject: Zapraszamy do zarobienia dodatkowo w wolnym czasie minimum 100 euro za godzine.
X-Mailer: vfvlsvltd
MIME-Version: 1.0
Content-Type: text/html;
charset=unicode
Content-Transfer-Encoding: 7bit
X-Antivirus: avast! (VPS 130911-0, 2013-09-11), Inbound message
X-Antivirus-Status: Clean
In Postfix to prevent this can do:
smtpd_recipient_restrictions = [...]
permit_sasl_authenticated,
check_sender_access proxy:mysql:/etc/postfix/mysql/mysql_virtual_nosasl.cf,
[...]
The first rule lets emails from users who have gone through SASL. The second checks to see if the sender's domain in the MAIL FROM is one of my domains. If so, it will block email from 554 Checking rules * _restrictions ends on the first match. So if the sender from my domain has not completed the permit_sasl_authenticated, it means that it is not my user and another rule should be blocked.
How do this with DirectAdmin exim.conf?
and more about spoofing
When an SMTP email is sent, the initial connection provides two pieces of address information:
MAIL FROM: - generally presented to the recipient as the Return-path: header but not normally visible to the end user,[6] and by default no checks are done that the sending system is authorized to send on behalf of that address.
RCPT TO: - specifies which email address the email is delivered to, is not normally visible to the end user but may be present in the headers as part of the "Received:" header.
Together these are sometimes referred to as the "envelope" addressing, by analogy with a traditional paper envelope.[7]
Once the receiving mail server signals that it accepted these two items, the sending system sends the "DATA" command, and typically sends several header items, including:
From: Joe Q Doe - the address visible to the recipient; but again, by default no checks are done that the sending system is authorized to send on behalf of that address.
Reply-to: Jane Roe - similarly not checked
The result is that the email recipient sees the email as having come from the address in the From: header; they may sometimes be able to find the MAIL FROM address; and if they reply to the email it will go to either the address presented in the MAIL FROM: or Reply-to: header - but none of these addresses are typically reliable.[8]
Furthermore the mail server may not check that these domains have been registered in the DNS and are configured to receive emails. This may generate backscatter if a reply is generated.
Related
I am accessing OneDrive from a C++ program using WinHttp* functions. What absolutely baffles me is REST API download command. I am downloading a small test picture with
GET /v1.0/drive/items/FF306293D40F9529!158/content
When I do this in the console, I get a response exactly as described in the docs, that is, a 302 redirect to the actual content. However when I send the same request with WinHttpSendRequest, I receive the actual file contents instead of a redirection:
HTTP/1.1 200 OK
Cache-Control: public
Date: Wed, 06 Jan 2016 10:22:36 GMT
Content-Length: 161796
Content-Type: image/jpeg
Content-Location: https://public-bn1306.files.1drv.com/blahblahbla
Expires: Tue, 05 Apr 2016 10:22:36 GMT
Last-Modified: Wed, 06 Jan 2016 10:22:35 GMT
Accept-Ranges: bytes
ETag: aRkYzMDYyOTNENDBGOTUyOSExNTguMw
P3P: CP="BUS CUR CONo FIN IVDo ONL OUR PHY SAMo TELo"
Server: Microsoft-IIS/8.5
X-MSNSERVER: BN1306____PAP099
Strict-Transport-Security: max-age=31536000; includeSubDomains
X-SqlDataOrigin: S
CTag: aYzpGRjMwNjI5M0Q0MEY5NTI5ITE1OC4yNTc
X-PreAuthInfo: rv;poba;
Content-Disposition: attachment; filename="Test.jpg"
X-Content-Type-Options: nosniff
X-StreamOrigin: X
X-AsmVersion: UNKNOWN; 19.33.0.0
X-MSEdge-Ref: Ref A: 44F40B6FB83547EFBC895911207BDB42 Ref B: 96336B0FC1B608598B549A1CB70C8C59 Ref C: Wed Jan 06 02:22:36 2016 PST
First I thought that maybe it was because the file was small, but trying to download a 250Mb large binary file changed nothing.
I don't complain actually, this would make the program a bit simpler, but I certainly would like to know why the same request works differently with WinHttp*. I suppose I do something wrong, but what??? (Banging my head against my desk.)
There are http libraries that will follow redirects automatically. You send a request, the library receives 302, and decides on its own to go to the redirect location, which then returns a 200.
I have a webpage (http://optiswissopen2015.ch/page/noticeboard) with some PDFs on it. All of them are linked the same way. But on some browsers (IE8 for sure) they are shown as text instead of open a pdf viewer.
<a href=" /files/Noticeboard/1436883318_sism2015.pdf"
download runat="server" class="button color3">
My first thought was, that they may have a problem in the header. But converting them to .ps and back doesn't help.
What can I do, that they open right with all browsers?
As a last option, I could ZIP them :-(
Yes, the the issue is in the file content type returned for some PDF files on your server. To verify it use curl -i [url] or wget -S [url] or this online tool.
For example, 1436883318_sism2015.pdf returns (incorrect):
HTTP/1.1 200 OK
ETag: "[omitted]"
Last-Modified: Tue, 14 Jul 2015 14:15:18 GMT
Content-Type: text/plain
Content-Length: 1188394
Date: Mon, 27 Jul 2015 17:19:21 GMT
Accept-Ranges: bytes
Server: LiteSpeed
Connection: close
And anmedleguide.pdf returns the correct header:
HTTP/1.1 200 OK
Date: Mon, 27 Jul 2015 17:21:25 GMT
Server: Apache/2.4.10 (Unix)
Last-Modified: Fri, 17 Jul 2015 13:07:01 GMT
ETag: "[omitted]"
Accept-Ranges: bytes
Content-Length: 932698
Content-Type: application/pdf
Why don't you try and integrate pdf.js.
I opened up your page in mozilla and the all the pdf's are being displayed nicely(Mozilla Firefox by default opens up a pdf in pdf.js). So you can integrate it in your website and get to display the pdf's in the same manner irrespective of the browser.
On the link below I have explained how to set-up pdf.js easily. (Just use your actual server instead of localhost mentioned there.)
Look on this link.
It will take only a few minutes to set-it up and the pdf issue will vanish for sure.
I developed an application using rails4 mongoid and devise by following the instructions at http://railsapps.github.io/tutorial-rails-mongoid-devise.html. Application is running successfully except confirmation mail and password reset instruction mail features. In my app logs it is showing something like:
Sent mail to csecse.great#gmail.com (8.4ms)
Date: Wed, 11 Dec 2013 13:56:39 +0530
From: sender#mail.com
Reply-To: sender#mail.com
To: csecse.great#gmail.com
Message-ID: <52a821bf82f6c_b1f3fc131e38fa07856e#TEST.local.mail>
Subject: Reset password instructions
Mime-Version: 1.0
Content-Type: text/html;
charset=UTF-8
Content-Transfer-Encoding: 7bit
I am getting this in logs whenever I am requesting for send password instructions but mail is not arriving to my mail id. please suggest me a solution for this.
I'm using Nginx + uwsgi + python3
Sending any header via start_response goes well, but when I want to send more than one header, it becomes mad.
For example, if I write:
start_response('200 OK', [('Last-Modified', 'Wed, 11 Jan 2012 00:00:00 GMT'), ('Content-Type', 'text/html; charset=windows-1251')])
The headers sent are:
HTTP/1.1 200 OK
Transfer-Encoding: chunked
Server: nginx/1.0.11
Connection: close
Date: Wed, 11 Jan 2012 04:17:22 GMT
Content-Type: text/html; charset=windows-1251
Content-Type: text/html; charset=windows-12
uwsgi sends the same header twice and even more the second one is broken.
which uWSGI and nginx version ? In both 0.9.8.x and 1.0.x i cannot reproduce your error.
You can check the real headers sent by uWSGI putting it in http mode with --http/--http-socket
I'm having a problem where items served by my Squid server are being cached by Limelight for too long, sometimes days. It happens when a piece of content has been static for a long time (weeks) and then undergoes numerous changes in a matter of hours.
Limelight gets its content from our Squid server and I'm told that if I can add 'Expires: 15m' in the HTTP header the Squid server sends, Limelight will not cache the image for more than 15 min.
Unfortunately, I can fond no setting in Squid that will allow me to add this to the header.
Here's the HTTP header as presently being sent:
HTTP/1.0 200 OK
Date: Tue, 15 Dec 2009 23:57:33 GMT
Server: nginx/0.5.26
Content-Type: image/jpeg
Content-Length: 83843
Last-Modified: Tue, 15 Dec 2009 23:52:00 GMT
Accept-Ranges: bytes
Age: 450
X-Cache: HIT from squid01.prod.mydomain
X-Cache-Lookup: HIT from squid01.prod.mydomain:3128
Via: 1.0 squid01.prod.mydomain:3128 (squid/2.6.STABLE14)
Connection: close
You need to set the header on the origin server, not on your Squid box.
See:
http://www.mnot.net/cache_docs/#IMP-SERVER