Hi All;
This is probably Off Topic, apologies...
I recently kicked googlemail to the curb in favor of a service that does not read my emails (fastmail). We are very happy with fastmail. We are using our own domain which I was also doing with google.
All of our clients can now email me at the same email address as before and I get the emails via fastmail, however we have one client that I do not receive the emails for. They can email me at other addresses but not the 'migrated' address. I'm not sure how to even start debugging this...
Any thoughts, ideas, suggestions would be much appreciated
Thanks in advance
On Wed, 2019-02-20 at 10:16 -0700, S. Bob wrote:
They can email me at other addresses but not the 'migrated' address. I'm not sure how to even start debugging this...
[Definitely OT, but anyway ...]
Do they get an error message back? Is their mail being dumped by a spam filter? Does Fastmail log messages sent to your address?
poc
On Wed, 2019-02-20 at 10:16 -0700, S. Bob wrote:
Hi All;
This is probably Off Topic, apologies...
I recently kicked googlemail to the curb in favor of a service that does not read my emails (fastmail). We are very happy with fastmail. We are using our own domain which I was also doing with google.
All of our clients can now email me at the same email address as before and I get the emails via fastmail, however we have one client that I do not receive the emails for. They can email me at other addresses but not the 'migrated' address. I'm not sure how to even start debugging this...
Any thoughts, ideas, suggestions would be much appreciated
Thanks in advance
This happened to me when I set up a mailinglist for a church group I belonged to. I ran a mail server I had in my home office that was hooked up to a cable service. Of the 50 people on the list, 20 could not send mail to the list -- even though they could receive mails.
It turned out that all of them were using one cable vendor and were getting their internet connection through it. I tried calling them, but the technical support folk there said it was my problem and they were not interested in spending time trying to help me -- so I was on my own.
I did a search on the problem at the time, and I wasn't the only person who ran into it. From my reading, it seemed that it was an issue of this particular ISP's internal security protocol that involved some sort of checking of ownership or something like that. The gist I got was that my domain resolved correctly, and the ICANN ownership info of the domain was correct, but the ownership of the some other component, like the IP address, was different, since it was tied to my ISP and not to me -- even though I was doing my own nameservice. Thus, I broke their spoofing rules. There was no solution that I could find, and none that worked for other folk who ran into it -- all of whom were running their own name and mail service from home.
The workaround I ended up using was to change the Reply To: address for those users to a big-name server address (gmail as I remember) and then forwarded that to my server, which it would do.
Note:
1) This was specific to one ISP (and the search turned it up only for that ISP) 2) It was back in 2008 3) I may not have characterized it correctly, since I didn't actually solve it.
billo
On 2/20/19 10:57 AM, William Oliver wrote:
On Wed, 2019-02-20 at 10:16 -0700, S. Bob wrote:
Hi All;
This is probably Off Topic, apologies...
I recently kicked googlemail to the curb in favor of a service that does not read my emails (fastmail). We are very happy with fastmail. We are using our own domain which I was also doing with google.
All of our clients can now email me at the same email address as before and I get the emails via fastmail, however we have one client that I do not receive the emails for. They can email me at other addresses but not the 'migrated' address. I'm not sure how to even start debugging this...
Any thoughts, ideas, suggestions would be much appreciated
Thanks in advance
This happened to me when I set up a mailinglist for a church group I belonged to. I ran a mail server I had in my home office that was hooked up to a cable service. Of the 50 people on the list, 20 could not send mail to the list -- even though they could receive mails.
It turned out that all of them were using one cable vendor and were getting their internet connection through it. I tried calling them, but the technical support folk there said it was my problem and they were not interested in spending time trying to help me -- so I was on my own.
I did a search on the problem at the time, and I wasn't the only person who ran into it. From my reading, it seemed that it was an issue of this particular ISP's internal security protocol that involved some sort of checking of ownership or something like that. The gist I got was that my domain resolved correctly, and the ICANN ownership info of the domain was correct, but the ownership of the some other component, like the IP address, was different, since it was tied to my ISP and not to me -- even though I was doing my own nameservice. Thus, I broke their spoofing rules. There was no solution that I could find, and none that worked for other folk who ran into it -- all of whom were running their own name and mail service from home.
The workaround I ended up using was to change the Reply To: address for those users to a big-name server address (gmail as I remember) and then forwarded that to my server, which it would do.
Note:
- This was specific to one ISP (and the search turned it up only for
that ISP) 2) It was back in 2008 3) I may not have characterized it correctly, since I didn't actually solve it.
Sounds like the same behavior, Thanks
billo _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
On 2/20/19 9:57 AM, William Oliver wrote:
On Wed, 2019-02-20 at 10:16 -0700, S. Bob wrote:
Hi All;
This is probably Off Topic, apologies...
I recently kicked googlemail to the curb in favor of a service that does not read my emails (fastmail). We are very happy with fastmail. We are using our own domain which I was also doing with google.
All of our clients can now email me at the same email address as before and I get the emails via fastmail, however we have one client that I do not receive the emails for. They can email me at other addresses but not the 'migrated' address. I'm not sure how to even start debugging this...
Any thoughts, ideas, suggestions would be much appreciated
Thanks in advance
This happened to me when I set up a mailinglist for a church group I belonged to. I ran a mail server I had in my home office that was hooked up to a cable service. Of the 50 people on the list, 20 could not send mail to the list -- even though they could receive mails.
It turned out that all of them were using one cable vendor and were getting their internet connection through it. I tried calling them, but the technical support folk there said it was my problem and they were not interested in spending time trying to help me -- so I was on my own.
I did a search on the problem at the time, and I wasn't the only person who ran into it. From my reading, it seemed that it was an issue of this particular ISP's internal security protocol that involved some sort of checking of ownership or something like that. The gist I got was that my domain resolved correctly, and the ICANN ownership info of the domain was correct, but the ownership of the some other component, like the IP address, was different, since it was tied to my ISP and not to me -- even though I was doing my own nameservice. Thus, I broke their spoofing rules. There was no solution that I could find, and none that worked for other folk who ran into it -- all of whom were running their own name and mail service from home.
You didn't have a dns delegation-of-authority which allows you to claim control or the mail server's reverse dns address and showing you're not some fly-by-night spammer or some such.
If your were to dig for the PTR record for the mailserver's IP you would get back something like 75-25-207-10.lightspeed.sjcpca.sbcglobal.net that indicates who is currently in charge of that IP. If you had the delegation-of-authority it would return YOUR mailserver's name.
e.g. 1st record shows name of mailserver for your domain 2nd record shows address of mailserver 3rd record ties the mailserver's address to it's IP
forward dns: yourchurch.org IN MX mx.yourchurch.org forward dns: mx.yourchurch.org IN A 192.168.10.20 reverse dns: 20.10.168.192.in-addr.arpa IN PTR mx.yourchurch.org
The delegations are usually available from your ISP if you're persistent and may come with a monthly fee. AT&T used to charge me $5 US but raised it to $15 because they could. Good bye AT&T, hello Digital Ocean: $5 for a basic server includes a delegated authority record.
The workaround I ended up using was to change the Reply To: address for those users to a big-name server address (gmail as I remember) and then forwarded that to my server, which it would do.
Note:
- This was specific to one ISP (and the search turned it up only for
that ISP) 2) It was back in 2008 3) I may not have characterized it correctly, since I didn't actually solve it.
billo _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
On Wed, 2019-02-20 at 13:09 -0800, Mike Wright wrote:
[snip] You didn't have a dns delegation-of-authority which allows you to claim control or the mail server's reverse dns address and showing you're not some fly-by-night spammer or some such.
If your were to dig for the PTR record for the mailserver's IP you would get back something like 75-25-207-10.lightspeed.sjcpca.sbcglobal.net that indicates who is currently in charge of that IP. If you had the delegation-of-authority it would return YOUR mailserver's name.
e.g. 1st record shows name of mailserver for your domain 2nd record shows address of mailserver 3rd record ties the mailserver's address to it's IP
forward dns: yourchurch.org IN MX mx.yourchurch.org forward dns: mx.yourchurch.org IN A 192.168.10.20 reverse dns: 20.10.168.192.in-addr.arpa IN PTR mx.yourchurch.org
The delegations are usually available from your ISP if you're persistent and may come with a monthly fee. AT&T used to charge me $5 US but raised it to $15 because they could. Good bye AT&T, hello Digital Ocean: $5 for a basic server includes a delegated authority record.
Yes! Now that you mention it, that's the buzzword I was blanking on. My mistake was that I thought that the delegation of authority was a configuration issue and I kept trying different ways of assigning it to myself in the bind configuration files and nothing worked. I got to that horrible point of just making random changes in random configuration files just to see if anything would change, and then gave up. I completely missed that I had to go to the ISP to get it.
Sigh. That's part of my life I'll never get back.
billo
Allegedly, on or about 20 February 2019, William Oliver sent:
The gist I got was that my domain resolved correctly, and the ICANN ownership info of the domain was correct, but the ownership of the some other component, like the IP address, was different, since it was tied to my ISP and not to me -- even though I was doing my own nameservice.
If the numerical IP address of your service is shared between yourselves and others, whether that's because your IP can change at different logins, or other's use it simultaneously (such as webserver hosts that service many clients on the same numerical IP), you're not going to get the host to point their reverse DNS look-up to your domain name. You need a permanently unique IP to be able to do that. The same situation applies for HTTPS and certificates (you need to be the sole user of your IP).
For shared IPs, the reverse lookup is going to be set to a hostname that suits the actual owner of the IP.
Related to the original problem, is a couple of the techniques used for spam rejection:
If your recipients checks that the IP your mail came through is one authorised to handle your mail, and that's not set, it'll be another problem for you. The domain name owner sets DNS SPF records listing the authorised services its mail goes through. This is something within your control, if you have proper control of your DNS records.
And another anti-spam technique that's related to your IP is the range of IPs known to be used by clients of ISPs is considered to be unsafe to accept mail from (as opposed to the range of IP addresses that the ISP's own mail services work from). If your recipient, or the services between you and the end-recipient, checks to see if you're using an ordinary customer IP, then your mail can be rejected for those reasons, too.
In short:
1. You need a mail server on an IP that the rest of the world is willing to receive mail from. This will cost you more, and the average consumer ISP might not be able to supply one to you.
2. Your forward and reverse DNS records should all return the same information (the answer to, "What IP is your mail server at?" should be the same answer as, "What is the hostname for the IP my mail server is at?" And your domain's MX record should point to your mailserver.
3. Your domain's DNS SPF records should list your authorised mail services. DKIM is a similar thing.
On 2/22/19 7:10 AM, Tim via users wrote:
If the numerical IP address of your service is shared between yourselves and others, whether that's because your IP can change at different logins, or other's use it simultaneously (such as webserver hosts that service many clients on the same numerical IP), you're not going to get the host to point their reverse DNS look-up to your domain name. You need a permanently unique IP to be able to do that. The same situation applies for HTTPS and certificates (you need to be the sole user of your IP).
This hasn't been true for a long time. I don't remember the acronym, but you can have an unlimited number of website hostnames on the same IP address that all have their own unique certificates.
- You need a mail server on an IP that the rest of the world is
willing to receive mail from. This will cost you more, and the average consumer ISP might not be able to supply one to you.
The ISPs here in Canada block port 25 so you can't directly send out. However, they provide a forwarder that you can send email through. You probably can't setup of SPF or DKIM (I haven't tried), but I've never had trouble sending mail from my server. I'm also not aware of anyone not being able to send to me as well.
Tim:
If the numerical IP address of your service is shared between yourselves and others, whether that's because your IP can change at different logins, or other's use it simultaneously (such as webserver hosts that service many clients on the same numerical IP), you're not going to get the host to point their reverse DNS look-up to your domain name. You need a permanently unique IP to be able to do that. The same situation applies for HTTPS and certificates (you need to be the sole user of your IP).
Samuel Sieb:
This hasn't been true for a long time. I don't remember the acronym, but you can have an unlimited number of website hostnames on the same IP address that all have their own unique certificates.
"SNI"? RFC'd in 2003, and still not supported by all browsers, but appears to be by all the major web server software.
I was under the impression that /that/ problem was unsolveable. Due to both web client and server first trying to connect *before* requesting the hostname, therefore it wasn't possible to provide a certificate for the right host. Of course if the HTTPS protocols have changed, but it appears not, just an addition has been made:
SNI put the requested domain name into the client's TLS negotiation, so the server can provide the right site's certificate.
The requested hostname is not encrypted, so it can be spied upon. Experiments are afoot to encrypt this, too, but only very recently (last year).
In most cases, it probably doesn't matter that some third party could find out you wanted to connect to a particular website (which used to be hidden with the old way of doing HTTPS, although they still knew the IP you were connecting to, and could see what DNS lookup you'd done just prior). But it can be used for surveillance and censorship.
On 2/22/19 10:15 PM, Tim via users wrote:
Samuel Sieb:
This hasn't been true for a long time. I don't remember the acronym, but you can have an unlimited number of website hostnames on the same IP address that all have their own unique certificates.
"SNI"? RFC'd in 2003, and still not supported by all browsers, but appears to be by all the major web server software.
Yes, that's the one and it's supported by all major browsers and most command line tools.
I was under the impression that /that/ problem was unsolveable. Due to both web client and server first trying to connect *before* requesting the hostname, therefore it wasn't possible to provide a certificate for the right host. Of course if the HTTPS protocols have changed, but it appears not, just an addition has been made:
SNI put the requested domain name into the client's TLS negotiation, so the server can provide the right site's certificate.
Right, it was unsolvable without extending the protocol. And it theoretically works for any protocol using TLS, not just HTTP.
The requested hostname is not encrypted, so it can be spied upon. Experiments are afoot to encrypt this, too, but only very recently (last year).
And won't be used for many years until client adoption is high enough, just like SNI.
In most cases, it probably doesn't matter that some third party could find out you wanted to connect to a particular website (which used to be hidden with the old way of doing HTTPS, although they still knew the IP you were connecting to, and could see what DNS lookup you'd done just prior). But it can be used for surveillance and censorship.
Without SNI, there would only be one website on an IP and you could get the hostname from the certificate anyway. So it doesn't really make any difference privacy-wise.
On Sat, 23 Feb 2019 14:46:48 -0800 Samuel Sieb samuel@sieb.net wrote:
Without SNI, there would only be one website on an IP and you could get the hostname from the certificate anyway. So it doesn't really make any difference privacy-wise.
another great reason to go to IPV6
d
-
Dave Stevens -
Mike Wright -
Patrick O'Callaghan -
S. Bob -
Samuel Sieb -
Tim -
William Oliver