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
Related
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.
So would username#gtld be a valid email? As a practical example google is purchasing the gTLD "gmail". Obviously they can associate A records with that permitting you to just type http://gmail/ to access the site. But, are there any specs that prohibit them from associating MX records with that as well, allowing folks to give out an alternative address username#gmail?
I ask because I want to make sure our email validator is future proof and technically correct.
I think I answered my own question. Section 3.4.1 of rfc5322 which defines a valid email address states:
addr-spec = local-part "#" domain
[...]
domain = dot-atom / domain-literal / obs-domain
[...]
The domain portion identifies the point to which the mail is delivered. In the dot-atom form, this is interpreted as an Internet domain name (either a host name or a mail exchanger name) as described in [RFC1034], [RFC1035], and [RFC1123]. In the domain-literal form, the domain is interpreted as the literal Internet address of the particular host.
"gmail" would be a valid domain and host name and thus someone#gtld is a valid email address.
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.