1 |
Am Tue, 8 Nov 2016 11:33:26 -0800 |
2 |
schrieb Ian Zimmerman <itz@×××××××.net>: |
3 |
|
4 |
> On 2016-11-08 15:14, Grant Edwards wrote: |
5 |
> |
6 |
> > You need a static IP address _and_ a domain name |
7 |
> |
8 |
> FreeDNS will provide the domain name, assuming you're content with a |
9 |
> 2nd level subdomain. You can examine the Received headers of this |
10 |
> mail to see how that works. |
11 |
> |
12 |
> > with an MX record that points to that static IP address |
13 |
> |
14 |
> MX records are optional. Per the RFCs, a conforming MTA MUST connect |
15 |
> to the address in the A record (provided by FreeDNS, of course) in the |
16 |
> absence of a MX. |
17 |
|
18 |
This is no longer optional as far as I know. MTAs still must do this |
19 |
fallback for compatibility but it is recommended to have an MX record. |
20 |
|
21 |
Some German mail providers even started to deny mails from senders |
22 |
without MX. And lately, one even denied delivering mails to receivers |
23 |
without MX (which somehow violates the above constraint but they |
24 |
convinced me, pointing to an RFC, that this is correct behavior on |
25 |
their site). So I added the missing MX on this particular domain. |
26 |
|
27 |
Getting the MX correct (with matching reverse and forward DNS) is very |
28 |
important to not have your mails classified as possible spam. So I |
29 |
cannot comply with your suggestion that MX is optional. Really: don't |
30 |
do it. Put an MX. |
31 |
|
32 |
BTW: I totally suggest against using a dynamic IP for MX purposes. You |
33 |
never know where your mail is delivered. There's chance that mail is |
34 |
delivered to a stale IP, and there's an SMTP server accepting all your |
35 |
mails. If you really want this, use ETRN at least, which probably won't |
36 |
be supported by the ordinary mail service provider (at least not in |
37 |
etrn-only mode). ETRN is an SMTP command to turn around roles: After |
38 |
authenticating, you can turn around roles and let the remote SMTP |
39 |
server spool all outstanding mails to your local SMTP through a new |
40 |
connection. This means, the destination site on the remote SMTP server |
41 |
has to be configured to put all your mails on the deferred queue until |
42 |
you connect and turn [1]. Still, this means you don't have the MX on |
43 |
your local site, just the second level MX (configured through a |
44 |
transport rule). This is somewhat similar to POP3 grabbing. In this |
45 |
case, the second level MX may be replaced by a simple A record, I |
46 |
believe. |
47 |
|
48 |
[1]: http://www.postfix.org/ETRN_README.html |
49 |
|
50 |
-- |
51 |
Regards, |
52 |
Kai |
53 |
|
54 |
Replies to list-only preferred. |