| 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. |
Archives