7 ms·

Why not follow the standards? The standard states a MX record contains a domain name that does not point to a CNAME record. If you don’t follow the standards t

Why not follow the standards? The standard states a MX record contains a domain name that does not point to a CNAME record. If you don’t follow the standards things might fail. That’s not someone else’s fault, it’s your fault.

8ytecoder 6y ago
>> There is one other special case. If the response contains an answer which is a CNAME RR, it indicates that REMOTE is actually an alias for some other domain name. The query should be repeated with the canonical domain name. https://tools.ietf.org/html/rfc974 https://tools.ietf.org/html/rfc974 (Page 3) In general, we expect systems to be forgiving.
DaiPlusPlus 6y ago
In this case, Courier is following the standard and it's failing, and it's the "fault" of the software. Courier is breaking (the aptly named) Postel's Law: "Be liberal in what you accept, and conservative in what you send." Courier is failing to be liberal in input-handling.
- corndoge 6y ago
  Postel's law was a good rule of thumb in the early wild west internet. In modern times I think it's largely anachronistic. Being liberal in what you accept leads to security problems, erosion of standards, growth of edge cases, etc.
  - young_unixer 6y ago
    I don't think anachronistic is the right description, but I agree that in some contexts Postel's law should not be followed. Postel's law is a good rule of thumb if you're writing a JSON library, but not if you're writing anything that has to do with security.
    - yjftsjthsd-h 6y ago
      JSON libraries are security-sensitive, though; they tend to get used on content coming from 3rd parties over the internet.
    - woodruffw 6y ago
      > Postel's law is a good rule of thumb if you're writing a JSON library, but not if you're writing anything that has to do with security. I'm a big fan of Postel's law in the context of UNIX tools, but I think that JSON is exactly the wrong example: JSON parsing is a security/format boundary, and I don't want my JSON (or any other parser) trying to suss structure out of something that's under- or unspecified. That way lies input confusion vulnerabilities.
      - DaiPlusPlus 6y ago
        Well, one example is having a JSON object property that is nominally typed as `number` but a JSON parser/library would also accept a number-in-a-string, so both `{ "foo": "123" }` and `{ "foo": 123 }` would be accepted. Storing numbers inside strings can be necessary if you're encountering JavaScript's 2^56 limit on integers, for example.
        woodruffw 6y ago
        > Well, one example is having a JSON object property that is nominally typed as `number` but a JSON parser/library would also accept a number-in-a-string, so both `{ "foo": "123" }` and `{ "foo": 123 }` would be accepted. This is a great example of "paving over bad behavior with worse behavior." If JSON is specified to only represent numbers that fit within a JavaScript double, then a correct parser must fail on numeric literals that don't fit into that type. It's up to me as a consumer to interpret strings that represent larger numbers. I've had this exact kind of "helpful" behavior cause potentially exploitable bugs in programs before: a complex system was using more than one JSON parser, and parser Foo would accept numeric inputs that parser Bar would silently fail on (mangling large numbers into garbage). The result was a potential arbitrary read primitive.
  - mytailorisrich 6y ago
    It's important to consider each decision. Sometimes it is not fine to be liberal, sometimes it is. In this case, I'd say that an MX record containing an IP address is not a big deal versus an MX pointing to an A record that contains an IP address, so one may consider that it makes sense to favour successful delivery of emails over strict enforcement of the standard and to accept it. That's pretty much what Postel's law is about and why many servers do accept it (though it also makes sense for a server to refuse to be configured that way even if it accepts it externally for robustness). Postel's law is not an anachronistic concept. This sort of design consideration applies everywhere in the real world.
- hannob 6y ago
  I thought about adding that, I should've... It's widely believed these days that postel's law was a mistake.
- chrisseaton 6y ago
  Do you want to send people email? Then you'll need to be liberal in what you accept.
  - tedunangst 6y ago
    Why can't the other party be conservative in what they send?
    - chokeartist 6y ago
      Go back to reddit. RFCs are standards but real life requires acceptance of divergence from the exact letter of the law.
    - chrisseaton 6y ago
      > Why can't the other party be conservative in what they send? Because they don't want to be? Because they don't know that they should be? Because they don't know how? Because they think they are but they're mistaken? Because the specification is ambiguous? Any number of reasons. But you can't control what they do. You can only control what you do. If you want to send an email to them, you need to be compatible with their email server.
- jeff-davis 6y ago
  I think there's some nuance here. Being liberal in what you accept is good for the growth and connectedness of a network. It's so powerful that it's not so much a suggestion as an inevitability -- if you're trying to be perfectly strict, then you will be excluded from the network and other people will find a way to be included. A party will always be bigger when you are less strict about the invitation/rsvp protocol. But it has obvious downsides. One is that the protocol keeps evolving, because people find novel ways to be non-conforming senders. This means an implementation is never "done". Another is that it becomes so hard to create a new implementation that accounts for all the non-conforming behavior, that the "standard" essentially becomes defined by a few of the big implementations.
- JdeBP 6y ago
  It is important to remember what Marc Crispin had to say about this: > Actually, Postel's principle is misstated. I knew Jon personally. He never advocated forcing implementations to accept bogus protocol, and it is a perverson of Jon's legacy to claim otherwise. > "Be liberal in what you accept" referred to accepting a wide range of valid protocol, as opposed to accepting only the most common form. If you consider the early protocols, such as Telnet and FTP, it was all too easy to create two compliant and non-interoperable implementations due to each implementation choosing a different subset. -- https://groups.google.com/g/alt.comp.mail.qmail/c/dcwx0Wc7ypU/m/--E_3AQB5QcJ https://groups.google.com/g/alt.comp.mail.qmail/c/dcwx0Wc7yp... > This statement is based upon a terrible misunderstand of Postel's robustness principle. I knew Jon Postel. He was quite unhappy with how his robustness principle was abused to cover up non-compliant behavior, and to criticize compliant software. -- https://groups.google.com/g/comp.mail.pine/c/E5ojND1L4u8/m/iYunDY6h_xMJ https://groups.google.com/g/comp.mail.pine/c/E5ojND1L4u8/m/i...
  - chrisseaton 6y ago
    > "Be liberal in what you accept" referred to accepting a wide range of valid protocol Have you considered that after some point you need to accept the de facto protocol as a valid protocol? If everyone else is using unnamed but extant protocol X, why fight that? What do you gain from it?
  - DonHopkins 6y ago
    Marc "MM Is Not At Fault" Crispin was also the author of the "infamous" RFC 748: Telnet Randomly-Lose Option. https://en.wikipedia.org/wiki/Mark_Crispin https://en.wikipedia.org/wiki/Mark_Crispin https://tools.ietf.org/html/rfc748 https://tools.ietf.org/html/rfc748 4. Motivation for the option. Several hosts appear to provide random lossage, such as system crashes, lost data, incorrectly functioning programs, etc., as part of their services. These services are often undocumented and are in general quite confusing to the novice user. A general means is needed to allow the user to disable these features.
eznzt 6y ago
Unless I'm missing something, the standard sounds pretty stupid
- tsimionescu 6y ago
  You're missing something: IPv4 is not the only type of physical address supported by DNS. There is also IPv6, and historically there were others. Instead of trying to parse the address and guess what protocol it might be, DNS tries to make that unambiguous: you ask it for the A or AAAA records for a domain name you are interested in, and you know for sure that you are getting an IPv4 or IPv6 address respectively. The only clean alternative would have been to make an MXMXMXMX record type to hold a domain name OR an IPv6 address.
- JdeBP 6y ago
  You are missing a lot, including the fact mentioned several times in this discussion that the data portion of an MX resource record simply is not an IP address. The data structure is a wire-format domain name (plus an integer). Even in BIND's "zone" file format, a human-format IP address isn't a fully qualified human-format domain name. But yes, the DNS RFCs are not as good as they could have been. However, you have reached that conclusion by the wrong route. (-:
andy_ppp 6y ago
Domain names and IP addresses are interchangeable almost everywhere else right? There already is a standard here and the spec is breaking it, not the other way around.
- apple4ever 6y ago
  That's how I feel. Specific records should not specify if its a domain name or an IP. They both should be accepted.
  - tsimionescu 6y ago
    So an A record should also hold domain names? Or IPv6 addresses? In DNS, there is actually a single record type that should hold a physical address, for each supported protocol address. We have A records for IPv4, and AAAA records for IPv6. Anything else should be a domain name. Adding both IPv4 and IPv6 support to every other record type would be a waste. Note: ignoring other protocol addresses above to keep it focused on what is currently is large scale use.
  - teddyh 6y ago
    DNS records are statically typed. An “A” record can only contain an IPv4 address, just like a variable of type “int” in the C programming language only can contain an integer. An MX record, just like CNAME, SRV, and others, can only contain a domain name, not an IP address of any kind. You can input a domain name which looks like an IPv4 address, but this is simply a syntax overlap; it happens to be that the normal textual representation of IPv4 addresses are also valid syntax for an unrelated domain name. Tellingly, the syntax for IPv6 addresses does not overlap with domain names, so you cannot make this error with IPv6 addresses.
- bawolff 6y ago
  Not really when it comes to dns. You cant put a domain name in an A record or an ip address in a CNAME.
  - andy_ppp 6y ago
chrisseaton 6y ago
> Why not follow the standards? Because they can't send email when they follow the standard? What are you trying to achieve? Following a standard for the sake of it, or are you actually trying to send email? And what's the point or use of a standard that people aren't following? What's the point of following such a standard?
- tinus_hn 6y ago
  No, it’s the other way around. You can’t receive mail from standards-compliant servers if you don’t follow the standard. What the point is of the standard requiring you to use a name instead of an IP address is a reasonable question but not the same question as whether you should follow the standards. Note this is a standard made by people who knew what they were doing and it has stood for 35 years. There’s always room for improvement but it would be a bit silly to think you can just handwave it away with arguments you can come up with in a few seconds. There is bound to be a catch. In this case the catch of course is that there are more address types than IPv4 addresses, so the system requires you to specify what kind of address you are talking about. The mechanism for that is the A record, which only holds IPv4 addresses.
Tomte 6y ago
Because you can't send mail everywhere, obviously. It's nice that it's the other person's fault. Still doesn't make your mail arrive.
osrec 6y ago
But does the standard make sense? What's the rationale for not using an IP address?
- tsimionescu 6y ago
  Because DNS works with many kinds of addresses, not just IPv4, and you shouldn't have to guess what type of address a record holds based on format. When you see an MX record with the value 1::8, how should you interpret it? Is it a malformed value? Is it an IPv6? Is it some other protocol that you don't know about? DNS clients shouldn't have to guess. Instead, the MX record should point to a domain name, and the client should look up the corresponding address record for the protocols it knows how to speak (A or AAAA or whatever else will exist).
  - DonHopkins 6y ago
    That is the best most irrefutable answer for why it's impossible I've seen so far. Better than "because it's physically impossible". (Is it electrically prevented at the Physical Layer, otherwise the router would catch fire if you tried to do that?)
    - teddyh 6y ago
      To be precise, it’s logically impossible, since MX records are defined by the relevant standards to consist of a number of bytes which are to be interpreted as a priority integer followed by a series of DNS domain name labels. There is no defined way for an MX record to contain an IP address. You could make up some such way, but then it wouldn’t be an MX record as commonly defined, it would be your private extension of the standards.
      - DonHopkins 6y ago
        "The standard definition tells you not to" isn't as deep and complete and useful an explanation as "the standard definition tells you not to, because networking protocols should not have ambiguities or make guesses". https://en.wikipedia.org/wiki/No_true_Scotsman https://en.wikipedia.org/wiki/No_true_Scotsman To be precise instead of tautological (which you should be when arguing the pedantic nuances of networking protocols), when you use a word like "physically", you're implying that it has something to do with the "Physical Layer", and that there could not exist another networking protocol in the same universe that DID allow IP addresses in MX records, because it's forbidden by the physical laws of nature, not by the logical laws of networking protocols. It's literally like using the word "literally" to mean "figuratively". (And I mean "literally" literally, not figuratively.) Obviously it's not physically impossible, because sometimes people do it, and sometimes it even works. I will agree that it's unwise and scandalous and logically impossible, just not "physically" impossible, and that a better explanation is needed. That's probably why the first reply to your comment was "Out of curiosity though: why is it like this?" A networking protocol that operates faster than the speed of light, or sends information backwards in time, could be physically impossible, according to the currently known laws of physics. Although it would be super cool and convenient if you could specify a "Date:" field in the past or the future to send email at the specified time.
sneak 6y ago
Because if you follow the standards, you can't send mail to some destinations, the issue the author is complaining about. It's the author's "fault" they can't send mail to those destinations when others can.
js2 6y ago
There's a de jure standard (the RFC) and a de facto standard (the real world). The question then becomes whether you want to be right or whether you want to be able to send mail.

8ytecoder 6y ago

>> There is one other special case. If the response contains an answer which is a CNAME RR, it indicates that REMOTE is actually an alias for some other domain name. The query should be repeated with the canonical domain name. https://tools.ietf.org/html/rfc974 https://tools.ietf.org/html/rfc974 (Page 3) In general, we expect systems to be forgiving.

DaiPlusPlus 6y ago

In this case, Courier is following the standard and it's failing, and it's the "fault" of the software. Courier is breaking (the aptly named) Postel's Law: "Be liberal in what you accept, and conservative in what you send." Courier is failing to be liberal in input-handling.

corndoge 6y ago
Postel's law was a good rule of thumb in the early wild west internet. In modern times I think it's largely anachronistic. Being liberal in what you accept leads to security problems, erosion of standards, growth of edge cases, etc.
- young_unixer 6y ago
  I don't think anachronistic is the right description, but I agree that in some contexts Postel's law should not be followed. Postel's law is a good rule of thumb if you're writing a JSON library, but not if you're writing anything that has to do with security.
  - yjftsjthsd-h 6y ago
    JSON libraries are security-sensitive, though; they tend to get used on content coming from 3rd parties over the internet.
  - woodruffw 6y ago
    > Postel's law is a good rule of thumb if you're writing a JSON library, but not if you're writing anything that has to do with security. I'm a big fan of Postel's law in the context of UNIX tools, but I think that JSON is exactly the wrong example: JSON parsing is a security/format boundary, and I don't want my JSON (or any other parser) trying to suss structure out of something that's under- or unspecified. That way lies input confusion vulnerabilities.
    - DaiPlusPlus 6y ago
      Well, one example is having a JSON object property that is nominally typed as `number` but a JSON parser/library would also accept a number-in-a-string, so both `{ "foo": "123" }` and `{ "foo": 123 }` would be accepted. Storing numbers inside strings can be necessary if you're encountering JavaScript's 2^56 limit on integers, for example.
      - woodruffw 6y ago
        > Well, one example is having a JSON object property that is nominally typed as `number` but a JSON parser/library would also accept a number-in-a-string, so both `{ "foo": "123" }` and `{ "foo": 123 }` would be accepted. This is a great example of "paving over bad behavior with worse behavior." If JSON is specified to only represent numbers that fit within a JavaScript double, then a correct parser must fail on numeric literals that don't fit into that type. It's up to me as a consumer to interpret strings that represent larger numbers. I've had this exact kind of "helpful" behavior cause potentially exploitable bugs in programs before: a complex system was using more than one JSON parser, and parser Foo would accept numeric inputs that parser Bar would silently fail on (mangling large numbers into garbage). The result was a potential arbitrary read primitive.
- mytailorisrich 6y ago
  It's important to consider each decision. Sometimes it is not fine to be liberal, sometimes it is. In this case, I'd say that an MX record containing an IP address is not a big deal versus an MX pointing to an A record that contains an IP address, so one may consider that it makes sense to favour successful delivery of emails over strict enforcement of the standard and to accept it. That's pretty much what Postel's law is about and why many servers do accept it (though it also makes sense for a server to refuse to be configured that way even if it accepts it externally for robustness). Postel's law is not an anachronistic concept. This sort of design consideration applies everywhere in the real world.
hannob 6y ago
I thought about adding that, I should've... It's widely believed these days that postel's law was a mistake.
chrisseaton 6y ago
Do you want to send people email? Then you'll need to be liberal in what you accept.
- tedunangst 6y ago
  Why can't the other party be conservative in what they send?
  - chokeartist 6y ago
    Go back to reddit. RFCs are standards but real life requires acceptance of divergence from the exact letter of the law.
  - chrisseaton 6y ago
    > Why can't the other party be conservative in what they send? Because they don't want to be? Because they don't know that they should be? Because they don't know how? Because they think they are but they're mistaken? Because the specification is ambiguous? Any number of reasons. But you can't control what they do. You can only control what you do. If you want to send an email to them, you need to be compatible with their email server.
jeff-davis 6y ago
I think there's some nuance here. Being liberal in what you accept is good for the growth and connectedness of a network. It's so powerful that it's not so much a suggestion as an inevitability -- if you're trying to be perfectly strict, then you will be excluded from the network and other people will find a way to be included. A party will always be bigger when you are less strict about the invitation/rsvp protocol. But it has obvious downsides. One is that the protocol keeps evolving, because people find novel ways to be non-conforming senders. This means an implementation is never "done". Another is that it becomes so hard to create a new implementation that accounts for all the non-conforming behavior, that the "standard" essentially becomes defined by a few of the big implementations.
JdeBP 6y ago
It is important to remember what Marc Crispin had to say about this: > Actually, Postel's principle is misstated. I knew Jon personally. He never advocated forcing implementations to accept bogus protocol, and it is a perverson of Jon's legacy to claim otherwise. > "Be liberal in what you accept" referred to accepting a wide range of valid protocol, as opposed to accepting only the most common form. If you consider the early protocols, such as Telnet and FTP, it was all too easy to create two compliant and non-interoperable implementations due to each implementation choosing a different subset. -- https://groups.google.com/g/alt.comp.mail.qmail/c/dcwx0Wc7ypU/m/--E_3AQB5QcJ https://groups.google.com/g/alt.comp.mail.qmail/c/dcwx0Wc7yp... > This statement is based upon a terrible misunderstand of Postel's robustness principle. I knew Jon Postel. He was quite unhappy with how his robustness principle was abused to cover up non-compliant behavior, and to criticize compliant software. -- https://groups.google.com/g/comp.mail.pine/c/E5ojND1L4u8/m/iYunDY6h_xMJ https://groups.google.com/g/comp.mail.pine/c/E5ojND1L4u8/m/i...
- chrisseaton 6y ago
  > "Be liberal in what you accept" referred to accepting a wide range of valid protocol Have you considered that after some point you need to accept the de facto protocol as a valid protocol? If everyone else is using unnamed but extant protocol X, why fight that? What do you gain from it?
- DonHopkins 6y ago
  Marc "MM Is Not At Fault" Crispin was also the author of the "infamous" RFC 748: Telnet Randomly-Lose Option. https://en.wikipedia.org/wiki/Mark_Crispin https://en.wikipedia.org/wiki/Mark_Crispin https://tools.ietf.org/html/rfc748 https://tools.ietf.org/html/rfc748 4. Motivation for the option. Several hosts appear to provide random lossage, such as system crashes, lost data, incorrectly functioning programs, etc., as part of their services. These services are often undocumented and are in general quite confusing to the novice user. A general means is needed to allow the user to disable these features.

eznzt 6y ago

Unless I'm missing something, the standard sounds pretty stupid

tsimionescu 6y ago
You're missing something: IPv4 is not the only type of physical address supported by DNS. There is also IPv6, and historically there were others. Instead of trying to parse the address and guess what protocol it might be, DNS tries to make that unambiguous: you ask it for the A or AAAA records for a domain name you are interested in, and you know for sure that you are getting an IPv4 or IPv6 address respectively. The only clean alternative would have been to make an MXMXMXMX record type to hold a domain name OR an IPv6 address.
JdeBP 6y ago
You are missing a lot, including the fact mentioned several times in this discussion that the data portion of an MX resource record simply is not an IP address. The data structure is a wire-format domain name (plus an integer). Even in BIND's "zone" file format, a human-format IP address isn't a fully qualified human-format domain name. But yes, the DNS RFCs are not as good as they could have been. However, you have reached that conclusion by the wrong route. (-:

andy_ppp 6y ago

Domain names and IP addresses are interchangeable almost everywhere else right? There already is a standard here and the spec is breaking it, not the other way around.

apple4ever 6y ago
That's how I feel. Specific records should not specify if its a domain name or an IP. They both should be accepted.
- tsimionescu 6y ago
  So an A record should also hold domain names? Or IPv6 addresses? In DNS, there is actually a single record type that should hold a physical address, for each supported protocol address. We have A records for IPv4, and AAAA records for IPv6. Anything else should be a domain name. Adding both IPv4 and IPv6 support to every other record type would be a waste. Note: ignoring other protocol addresses above to keep it focused on what is currently is large scale use.
- teddyh 6y ago
  DNS records are statically typed. An “A” record can only contain an IPv4 address, just like a variable of type “int” in the C programming language only can contain an integer. An MX record, just like CNAME, SRV, and others, can only contain a domain name, not an IP address of any kind. You can input a domain name which looks like an IPv4 address, but this is simply a syntax overlap; it happens to be that the normal textual representation of IPv4 addresses are also valid syntax for an unrelated domain name. Tellingly, the syntax for IPv6 addresses does not overlap with domain names, so you cannot make this error with IPv6 addresses.
bawolff 6y ago
Not really when it comes to dns. You cant put a domain name in an A record or an ip address in a CNAME.
- andy_ppp 6y ago

chrisseaton 6y ago

> Why not follow the standards? Because they can't send email when they follow the standard? What are you trying to achieve? Following a standard for the sake of it, or are you actually trying to send email? And what's the point or use of a standard that people aren't following? What's the point of following such a standard?

tinus_hn 6y ago
No, it’s the other way around. You can’t receive mail from standards-compliant servers if you don’t follow the standard. What the point is of the standard requiring you to use a name instead of an IP address is a reasonable question but not the same question as whether you should follow the standards. Note this is a standard made by people who knew what they were doing and it has stood for 35 years. There’s always room for improvement but it would be a bit silly to think you can just handwave it away with arguments you can come up with in a few seconds. There is bound to be a catch. In this case the catch of course is that there are more address types than IPv4 addresses, so the system requires you to specify what kind of address you are talking about. The mechanism for that is the A record, which only holds IPv4 addresses.

Tomte 6y ago

Because you can't send mail everywhere, obviously. It's nice that it's the other person's fault. Still doesn't make your mail arrive.

osrec 6y ago

But does the standard make sense? What's the rationale for not using an IP address?

tsimionescu 6y ago
Because DNS works with many kinds of addresses, not just IPv4, and you shouldn't have to guess what type of address a record holds based on format. When you see an MX record with the value 1::8, how should you interpret it? Is it a malformed value? Is it an IPv6? Is it some other protocol that you don't know about? DNS clients shouldn't have to guess. Instead, the MX record should point to a domain name, and the client should look up the corresponding address record for the protocols it knows how to speak (A or AAAA or whatever else will exist).
- DonHopkins 6y ago
  That is the best most irrefutable answer for why it's impossible I've seen so far. Better than "because it's physically impossible". (Is it electrically prevented at the Physical Layer, otherwise the router would catch fire if you tried to do that?)
  - teddyh 6y ago
    To be precise, it’s logically impossible, since MX records are defined by the relevant standards to consist of a number of bytes which are to be interpreted as a priority integer followed by a series of DNS domain name labels. There is no defined way for an MX record to contain an IP address. You could make up some such way, but then it wouldn’t be an MX record as commonly defined, it would be your private extension of the standards.
    - DonHopkins 6y ago
      "The standard definition tells you not to" isn't as deep and complete and useful an explanation as "the standard definition tells you not to, because networking protocols should not have ambiguities or make guesses". https://en.wikipedia.org/wiki/No_true_Scotsman https://en.wikipedia.org/wiki/No_true_Scotsman To be precise instead of tautological (which you should be when arguing the pedantic nuances of networking protocols), when you use a word like "physically", you're implying that it has something to do with the "Physical Layer", and that there could not exist another networking protocol in the same universe that DID allow IP addresses in MX records, because it's forbidden by the physical laws of nature, not by the logical laws of networking protocols. It's literally like using the word "literally" to mean "figuratively". (And I mean "literally" literally, not figuratively.) Obviously it's not physically impossible, because sometimes people do it, and sometimes it even works. I will agree that it's unwise and scandalous and logically impossible, just not "physically" impossible, and that a better explanation is needed. That's probably why the first reply to your comment was "Out of curiosity though: why is it like this?" A networking protocol that operates faster than the speed of light, or sends information backwards in time, could be physically impossible, according to the currently known laws of physics. Although it would be super cool and convenient if you could specify a "Date:" field in the past or the future to send email at the specified time.

sneak 6y ago

Because if you follow the standards, you can't send mail to some destinations, the issue the author is complaining about. It's the author's "fault" they can't send mail to those destinations when others can.

js2 6y ago

There's a de jure standard (the RFC) and a de facto standard (the real world). The question then becomes whether you want to be right or whether you want to be able to send mail.