'Prevent sender address spoofing' not working
'Prevent sender address spoofing' not working
I have a big problem with spam emails which have identical to/from address , supposedly from local domains. So I switched on the 'Prevent sender address spoofing' but it did not fix the problem: I am still getting emails TO/FROM me@mydomain.com (where mydomain.com is a local domain).
Why didn't this fix my problem ?
Why didn't this fix my problem ?
-
- Site Admin
- Posts: 9738
- Joined: Mon Mar 22, 2004 4:44 am
- Location: Melbourne, Victoria, Australia
Hi,
Can you provide a log snippet of the incoming message from the SMTP log files.
Another suggestion is to enable SPF checking and create an SPF record for your domain as this also another effective method of preventing sender address spoofing. More information can be found here: http://www.mailenable.com/kb/Content/Ar ... D=me020345
Can you provide a log snippet of the incoming message from the SMTP log files.
Another suggestion is to enable SPF checking and create an SPF record for your domain as this also another effective method of preventing sender address spoofing. More information can be found here: http://www.mailenable.com/kb/Content/Ar ... D=me020345
Regards,
Ian Margarone
MailEnable Support
Ian Margarone
MailEnable Support
We already have SPF enabled - not too sure how much it is helping but I'm getting about 50 emails a day where the FROM/TO is the same/our domain.
I wasn't too sure which SMTP log you wanted data from so this is from the Connectors > SMTP > Logs > Activity:
12/17/08 21:39:39 SMTP-IN 4B173F18614F40669D3B8672EBEC5C7B.MAI 668 190.198.163.132 220 burning-petals.com ESMTP MailEnable Service, Version: 0-2.37- ready at 12/17/08 21:39:39 0 0
12/17/08 21:39:39 SMTP-IN 4B173F18614F40669D3B8672EBEC5C7B.MAI 668 190.198.163.132 HELO HELO ofictinto.cantv.net 250 Requested mail action okay, completed 43 26
12/17/08 21:39:39 SMTP-IN 4B173F18614F40669D3B8672EBEC5C7B.MAI 668 190.198.163.132 MAIL MAIL FROM:<RupertdangerBoyle@villageofjackson.com> 250 Requested mail action okay, completed 43 52
12/17/08 21:39:39 SMTP-IN 4B173F18614F40669D3B8672EBEC5C7B.MAI 668 190.198.163.132 RCPT RCPT TO:<richard@thebrokernetwork.info> 250 Requested mail action okay, completed 43 41
12/17/08 21:39:39 SMTP-IN 4B173F18614F40669D3B8672EBEC5C7B.MAI 668 190.198.163.132 DATA DATA 354 Start mail input; end with <CRLF>.<CRLF> 46 6
12/17/08 21:39:40 SMTP-IN 2E488082A01448AC9AB1D4F6F71B9C01.MAI 668 190.198.163.132 QUIT QUIT 221 Service closing transmission channel 42 6 Discount ID: 3923
In my email client the FROM/TO address are the same. The address shown above as the FROM address, for this email, is shown as being the RETURN PATH in my email client.
I wasn't too sure which SMTP log you wanted data from so this is from the Connectors > SMTP > Logs > Activity:
12/17/08 21:39:39 SMTP-IN 4B173F18614F40669D3B8672EBEC5C7B.MAI 668 190.198.163.132 220 burning-petals.com ESMTP MailEnable Service, Version: 0-2.37- ready at 12/17/08 21:39:39 0 0
12/17/08 21:39:39 SMTP-IN 4B173F18614F40669D3B8672EBEC5C7B.MAI 668 190.198.163.132 HELO HELO ofictinto.cantv.net 250 Requested mail action okay, completed 43 26
12/17/08 21:39:39 SMTP-IN 4B173F18614F40669D3B8672EBEC5C7B.MAI 668 190.198.163.132 MAIL MAIL FROM:<RupertdangerBoyle@villageofjackson.com> 250 Requested mail action okay, completed 43 52
12/17/08 21:39:39 SMTP-IN 4B173F18614F40669D3B8672EBEC5C7B.MAI 668 190.198.163.132 RCPT RCPT TO:<richard@thebrokernetwork.info> 250 Requested mail action okay, completed 43 41
12/17/08 21:39:39 SMTP-IN 4B173F18614F40669D3B8672EBEC5C7B.MAI 668 190.198.163.132 DATA DATA 354 Start mail input; end with <CRLF>.<CRLF> 46 6
12/17/08 21:39:40 SMTP-IN 2E488082A01448AC9AB1D4F6F71B9C01.MAI 668 190.198.163.132 QUIT QUIT 221 Service closing transmission channel 42 6 Discount ID: 3923
In my email client the FROM/TO address are the same. The address shown above as the FROM address, for this email, is shown as being the RETURN PATH in my email client.
-
- Site Admin
- Posts: 9738
- Joined: Mon Mar 22, 2004 4:44 am
- Location: Melbourne, Victoria, Australia
Hi,
Firstly I would suggest that you download the latest version 2.53 located at the link below and perform the upgrade as it contains extensive security fixes to all services and options to eliminate issues within 2.37 that you are currently running.
You can find the kit here: http://www.mailenable.com/professional253.EXE
The following KB article can assist you with the upgrade procedure: http://www.mailenable.com/kb/viewarticl ... 020040.htm
Firstly I would suggest that you download the latest version 2.53 located at the link below and perform the upgrade as it contains extensive security fixes to all services and options to eliminate issues within 2.37 that you are currently running.
You can find the kit here: http://www.mailenable.com/professional253.EXE
The following KB article can assist you with the upgrade procedure: http://www.mailenable.com/kb/viewarticl ... 020040.htm
Regards,
Ian Margarone
MailEnable Support
Ian Margarone
MailEnable Support
-
- Site Admin
- Posts: 9738
- Joined: Mon Mar 22, 2004 4:44 am
- Location: Melbourne, Victoria, Australia
I have the same problem!!, i think that is because the filter only checks the return path or envelope and not the from
I saw this in from line my own address but in the return path another domain, that even pass the SPF!!!! because the return path is from another domian but i continue see my own address en the from
In this way the prevent address spoofing and SPF options just don't work!.
I have the latest PRO 3.6
I saw this in from line my own address but in the return path another domain, that even pass the SPF!!!! because the return path is from another domian but i continue see my own address en the from
In this way the prevent address spoofing and SPF options just don't work!.
I have the latest PRO 3.6
-
- Site Admin
- Posts: 9738
- Joined: Mon Mar 22, 2004 4:44 am
- Location: Melbourne, Victoria, Australia
Hi,
Have you correctly setup an SPF record for your domain? Do you see the SPF header line within the message headers?
Enabling the option "prevent sender address spoofing" within the SMTP security options window is an effective way to stop sender address spoofing as it will enforce inbound authentication when messages are sent from/to local addresses.
Have you correctly setup an SPF record for your domain? Do you see the SPF header line within the message headers?
Enabling the option "prevent sender address spoofing" within the SMTP security options window is an effective way to stop sender address spoofing as it will enforce inbound authentication when messages are sent from/to local addresses.
Regards,
Ian Margarone
MailEnable Support
Ian Margarone
MailEnable Support
Is enabled and my SPF in very strict -all.
Can you see that the SPF checks the domain on the return path and the FROM that is the "NORMAL" people see is not checked!! in this case is a softfail and in some cases pass because don't check my domain SPF
It must be something like
Received-SPF: fail (my.server: domain of my.domain.com does not designate 124.122.157.241 as permitted sender) client-ip=124.122.157.241;
NOTE : This IP is not mine 124.122.157.241
Code: Select all
Received: from ppp-124-120-234-127.revip2.asianet.co.th ([124.122.157.241]) by myserver with MailEnable ESMTP; Fri, 13 Mar 2009 22:29:48 -0600
To: <my@domain>
Subject: for my@domain
From: <my@domain>
MIME-Version: 1.0
Importance: High
Content-Type: text/html
Received-SPF: softfail (my.server: transitioning domain of amdahl.com does not designate 124.122.157.241 as permitted sender)
client-ip=124.122.157.241;
Return-Path: <kbozeman@amdahl.com>
X-EsetId: AE3A0925D5D15437FD7C
It must be something like
Received-SPF: fail (my.server: domain of my.domain.com does not designate 124.122.157.241 as permitted sender) client-ip=124.122.157.241;
NOTE : This IP is not mine 124.122.157.241
-
- Site Admin
- Posts: 9738
- Joined: Mon Mar 22, 2004 4:44 am
- Location: Melbourne, Victoria, Australia
I'm using Enterprise 3.6.1 and having the same problem described above. Has any solution been found yet?mammdo wrote:I have the same problem!!, i think that is because the filter only checks the return path or envelope and not the from
I saw this in from line my own address but in the return path another domain ...
My first priority is to get the "address spoofing" working because that would block a lot of spam, and reduce phishing.
My second priority is to get SPF to verify both the FROM and REPLY-TO domains. My SPF settings reject only 'failures', so this is not my primary defense against spam - but it does catch quite a bit.
So is there a way to get ME to pay attention to the FROM address, and not just check the REPLY-TO address? Spammers use an external replyto address to avoid being rejected, yet they are still spoofing the address that actually *displays* in the mail client. This makes both the anti-spoofing and SPF features useless against them!
Hopefully there is a way to plug this hole.
Kevin Dalman
-
- Site Admin
- Posts: 4441
- Joined: Tue Jun 25, 2002 3:03 am
- Location: Melbourne, Victoria Australia
Re: 'Prevent sender address spoofing' not working
Hi Kevin,
I am replying to your old post because someone recently raised a question on this with our sales team.
To explain the context of SPF and Spoofing requires a little more insight into how e-mail messages are transmitted.
Just like regular postage mail, there are two main components to sending an e-mail message via SMTP. There is the envelope and the message contents. The SMTP log file contains the details of the envelope (the actual transmission commands sent in when routing the message) whilst the message content (the stuff you see in the mail client itself) is an entirely seperate entity (the message content also contains the message headers and the text and attachments you see within the e-mail client). To be clear, the message contents/data actualy include the headers (from, to, etc) - and these are not required to relate to the envelope information.
Consider how (with regular postal mail) it is possible for you to send an e-mail to a friend, and yet include anything you like inside the envelope. The same applies with electronic e-mail.
SPF by design works on the Envelope information (it is not designed to and cannot work on the message contents for a number of reasons). Sender address spoofing also works on the enveloper information, and serves the purpose of restricting the envelope information (specifically the sender).
Not back to this comment:
SPF and Address Spoofing cannot be be used to validate a message since they work on the envelope information (this is the case with any mail server - or at least any mail server that adheres to the RFCs/Internet Standards).
So, the problem you have is really how to stop spam that has come from what appears to be a valid source.
The simplest and most reliable solution is to use the envelope information (the stuff that cannot be forged). This would include ensuring that the sender is not on a blacklist (that their IP address is not known to generate Spam). You can also use consider using Greylisting (that will have an immediate effect in stoping these messages).
Now for some more good news....
Although its not possible/feasilble to use SPF as a means of discriminating against these messages (because its not designed to do so), MailEnable already has filters that check this, and use it to identify POSSIBLE Spam. This can be configured/reviewed under the MMC/Messaging Manager/Spam Protection section. Its called "Envelope sender does not match header sender". The default weight is 20, but you can increase that to 30 (or higher) if you would like to discriminate against those e-mails.
That setting will apply system wide - but (depending on your version), you can define more rigid filters at a mailbox/postoffice level using mailbox/postoffice filtering.
I am replying to your old post because someone recently raised a question on this with our sales team.
To explain the context of SPF and Spoofing requires a little more insight into how e-mail messages are transmitted.
Just like regular postage mail, there are two main components to sending an e-mail message via SMTP. There is the envelope and the message contents. The SMTP log file contains the details of the envelope (the actual transmission commands sent in when routing the message) whilst the message content (the stuff you see in the mail client itself) is an entirely seperate entity (the message content also contains the message headers and the text and attachments you see within the e-mail client). To be clear, the message contents/data actualy include the headers (from, to, etc) - and these are not required to relate to the envelope information.
Consider how (with regular postal mail) it is possible for you to send an e-mail to a friend, and yet include anything you like inside the envelope. The same applies with electronic e-mail.
SPF by design works on the Envelope information (it is not designed to and cannot work on the message contents for a number of reasons). Sender address spoofing also works on the enveloper information, and serves the purpose of restricting the envelope information (specifically the sender).
Not back to this comment:
MailEnable does use the FROM address (the envelope FROM address), which typically is the same as the Reply-To address that is represented in the message contents.So is there a way to get ME to pay attention to the FROM address, and not just check the REPLY-TO address? Spammers use an external replyto address to avoid being rejected, yet they are still spoofing the address that actually *displays* in the mail client.
SPF and Address Spoofing cannot be be used to validate a message since they work on the envelope information (this is the case with any mail server - or at least any mail server that adheres to the RFCs/Internet Standards).
So, the problem you have is really how to stop spam that has come from what appears to be a valid source.
The simplest and most reliable solution is to use the envelope information (the stuff that cannot be forged). This would include ensuring that the sender is not on a blacklist (that their IP address is not known to generate Spam). You can also use consider using Greylisting (that will have an immediate effect in stoping these messages).
Now for some more good news....
Although its not possible/feasilble to use SPF as a means of discriminating against these messages (because its not designed to do so), MailEnable already has filters that check this, and use it to identify POSSIBLE Spam. This can be configured/reviewed under the MMC/Messaging Manager/Spam Protection section. Its called "Envelope sender does not match header sender". The default weight is 20, but you can increase that to 30 (or higher) if you would like to discriminate against those e-mails.
That setting will apply system wide - but (depending on your version), you can define more rigid filters at a mailbox/postoffice level using mailbox/postoffice filtering.
Regards, Andrew
Re: 'Prevent sender address spoofing' not working
Thanks for taking the time to respond. At the time I posted that, I was being inundated with spoofed emails - thousands per day - and it was very frustrating to not be able to block or flag them.
I have since added the MxScan utility for ME and that helped cut the spam dramatically. But things can always be improved, so I took you advise and increased the weight of the "Envelope sender does not match header" filter to 40. I have ME set to just flag messages with an altered subject line, so I'll be able to see if it makes a difference. (I'm not sure off-hand if MxScan already addresses this issue sufficiently?)
Thanks again for the information.
/Kevin
PS: When I looked at the latest demo of ME, I noticed that it uses my jQuery plug-in (UI Layout) for its interface. So I've been planning to hit up the sales team for a free upgrade of my Enterprise version, since I may then be able to suggest/offer some enhancements, but I just haven't gotten around to it!
I have since added the MxScan utility for ME and that helped cut the spam dramatically. But things can always be improved, so I took you advise and increased the weight of the "Envelope sender does not match header" filter to 40. I have ME set to just flag messages with an altered subject line, so I'll be able to see if it makes a difference. (I'm not sure off-hand if MxScan already addresses this issue sufficiently?)
Thanks again for the information.
/Kevin
PS: When I looked at the latest demo of ME, I noticed that it uses my jQuery plug-in (UI Layout) for its interface. So I've been planning to hit up the sales team for a free upgrade of my Enterprise version, since I may then be able to suggest/offer some enhancements, but I just haven't gotten around to it!