I have checked my IP in SpamRATS and the result is the following:
Standards Compliance
Does IP Address resolve to a reverse hostname... Passed!
Does IP Address comply with reverse hostname naming convention... Passed!
List Status
RATS-Dyna - On the list. Worst Offender Alert
RATS-NoPtr - Not on the list
RATS-Spam - Not on the list
I have tried to do the suggestion in their removal page but it still doesn't work. Any suggestions on how can I remove the IP in the list and what can I do so that I won't be listed again.
The Worst Offender list means that the entire class C of your IP address has been identified as an issue. The owner of the IP addresses have to appeal with RATS. There is nothing you can do to from the normal removal form.
Related
I need disposable email addresses with random address extensions such as:
api+test1#domain.net
api+test2#domain.net
...
All these addresses can be delivered to the local mailbox api without any problem, however, I have to forward them to a remote mail account api#domain.com (which does not recognize address extensions).
Here's the current config:
# main.cf
recipient_delimiter = +
# virtual
api#domain.net api#domain.com
The forward works, however, api+test1#domain.net is forwarded to api+test1.domain.com and can't be delivered there (since it does not recognize address extensions).
How can I "drop" the address extension before the mails are forwarded? In other words, how can I forward all addresses api+*#domain.net to api#domain.com?
(I've tried a canonical map api+test1 api which didn't do the trick.)
Thanks for your hints!
Figured it out: You can redirect extension addresses in virtual directly:
api+test1#domain.net api#domain.com
And with a pcre table instead of hash, one line can treat them all:
/^api+.+#domain.net$/ api#domain.com
I've set up MX records as such:
5 # ALT1.ASPMX.L.GOOGLE.COM
5 # ALT2.ASPMX.L.GOOGLE.COM
10 # ALT3.ASPMX.L.GOOGLE.COM
10 # ALT4.ASPMX.L.GOOGLE.COM
1 # ASPMX.L.GOOGLE.COM
CNAME as such:
www xxxx.rhcloud.com
The problem is that xxxx.com does not resolve to www.xxxx.com in a web browser.
The second problem is that emails sent to xxxx.com return with "DNS Error: Address resolution of xxxx.ca. failed: DNS server returned answer with no data". And before, "The recipient server did not accept our requests to connect.".
Another thing was this. Not sure what that is.
I've seen some hints on the internet to set up an A record to route # to the IP of the server, but rhcloud dosen't have one IP, I don't think.
I'm completely out of my depth here. I just want my google apps emails to work, and website to direct trafic to my rhcloud server.
You can't set your root domain as CNAME, only subdomain can be CNAME.
Root domain must have A-record if you want correct redirect to www.yoursite.com in web browser.
I've seen some hints on the internet to set up an A record to route # to the IP of the server, but rhcloud dosen't have one IP, I don't think.
Symbol "#" in DNS zone means "root domain without subdomains, so this two record are equal:
NAME TYPE VALUE
--------------------------------------------------
someexample.com. A 55.33.11.22
# A 55.33.11.22
I don't know how openshift works, but looks like you can have only subdomain directed to your xxx.openshift.com application.
Issues with MX records in is unrelated to first question and I can't say what actually wrong.
Will be better if you show your real domain name so I can look on real zone configuration.
I'm trying to test a new email validation function I've written, based on this one., but with some minor adjustments.
From a large set of valid and invalid entries, the function finds just one false negative - an address which has an IPv6 address instead of a domain.
user#[IPv6:2001:db8:1ff::a0b:dbd0]
The source is this wikipedia page: Email Addresses
However, System.Net.IPAddress fails to parse IPv6:2001:db8:1ff::a0b:dbd0, and I can't find any references in the RFC4291 to any prefix of IPv6.
Obviously, IPv6:2001:db8:1ff::a0b:dbd0 is not a valid IPv6 address, but is it valid in an email address? Or is wikipedia wrong?
Should the actual email be user#[2001:db8:1ff::a0b:dbd0] Anyone know?
You are right to look at RFC4291 for the IPv6 address format. However, for SMTP (and thus for any other email software handling addresses) you should also look at Address Literals in RFC5321.
The one you want is probably "IPv6-address-literal".
For those still looking for this, the IPv6: prefix tag is required.
https://www.rfc-editor.org/rfc/rfc5321#section-4.1.3
For IPv6 and other forms of addressing that might eventually be standardized, the form consists of a standardized "tag" that identifies the address syntax, a colon, and the address itself ...
I host a spread of different domains that all use my (one) mail-server to send and receive mail. When sending mails, sometimes, my mail gets rejected by the receiving end, marked to the recipient as "suspicious" or simply heads straight for the spam folder.
Also, on the inbound, I get a load of "return receipts" from random victims of spam, where one of my domain names has been used even though the mail never touched my mail server.
I have been told, that both issues stems from the fact, that my SPF record is not set properly which i have been attempting to fix for quite a while now. Unfortunately my basic knowledge of the mechanisms behind the record and the syntax itself escapes me somewhat, which is why I'm looking here for help.
For the purpose of the following example, assume the following setup:
I have two domains: mydomain.com and myotherdomain.com.
Both domains have active subdomains that send and receive mail through my mailserver.
My mail server is named mail.mydomain.com
All running on the same physical server with the IP address: 85.81.xxx.xxx.
I have a semi-static IP-address with my ISP, e.g. it never changes but is per say not mine to call my own. A whois on 85.81.xxx.xxx produces 0x39Axxxx.dslpool.isp.com
Using the tool found at http://tools.bevhost.com/spf/ i end up with the following conclusion:
Email Origin : Pass - 85.81.xx.xx
resolves to
0x39Axxxx.dslpool.isp.com which then
again resolves to 85.81.xx.xx.
Sender Details : Pass -
myname#myotherdomain.net points to a
MX-record that points to my mail sever
at mail.mydomain.net.
Host Name HELO / EHLO : Fail -
mail.mydomian.not resolves to
85.81.xxx.xxx which resolves to
0x39Axxxx.dslpool.isp.com
So, the question is: If at all possible, how would I compose the SPF entries for mydomain.com and myotherdomain.com to disregard this conflict and allow my sent mails to appear valid when spf validated by the receiver?
Hoping for a response ...
Here you should have this SPF entry in your DNS v=spf1 +ip4:85.81.xxx.xxx -all for all your domains, and nothing more in your SPF string.
Make sure that you have such a DNS entry for mail.maydomain.com as well as mydomain.com,
because the SPF entry for mydomain.com is not valid for subdomain.mydomain.com.
If you have many subdomains,you may consider to have an SPF entry for *.maydomain.com. That will take care of all the domain tree that are sub or sub.sub or sub.sub.sub etc. domains of the domain mydomain.com.
I'm writing a SIP stack, and I need to insert an ip address in the message. This address needs to be the one used for sending the message. I know the destination IP and need to determine the NIC (its address) that will be used to send the message....
To expand a bit on Remy Lebeau's comment, GetBestInterfaceEx() is your best bet, if you're on Windows XP or newer. That will work for both IPv4 and IPv6 addresses.
GetBestInterface/GetBestInterfaceEx return the index (call it IDX) of the most appropriate interface to use to contact some address.
Then you can map that index into a local IP address by getting your interface<->IP address mapping using GetIpAddrTable or GetAdaptersAddresses if you're dual-stacking (supporting both IPv6 and IPv4).
Iterate over that table and find the interface with the dwIndex (or IfIndex, in the case of GetAdaptersAddresses) matching IDX.
It's usually best to allow the IP address your SIP stack will operate on to be set as an adjustable configuration option. It means the user will need to set a configuration option but at least your stack will know the IP address it's operating on.
If that's not feasible then an approach you could use is to send out the SIP request on all IP addresses using a dummy value in the Via header such as 0.0.0.0 and set the interface you get a response back on as the default one. This approach alos as the advantage that the SIP response will tell you the public IP address the request was received from which can be useful if your SIP stack is behind a NAT.
Over TCP, I think you can get the address of the local side of the socket after connect(). I don't know if the same is true for UDP (I suspect not), but it might be worth a try.
The socket will allow you to Bind to a local endpoint before calling connect (both UDP and TCP).
That is all ok if you know the port. However, if you want the port to be ephemeral (e.g. some random port number) then you must come up with your own algorithm to do so and robust code to handle the cases where the port is exclusivly taken by another application.