• Dumb Question is an A or AAAA record required?

    From @lbutlr@kremels@kreme.com to bind-users on Thu Jul 9 06:21:55 2020
    From Newsgroup: comp.protocols.dns.bind

    Given a domain that is hosted and used for email and web, is an A record for that domain actually required?
    That is, if bob.tld is hosted by example.com can you simply have
    NS ns1.example.com
    NS ns2.example.com
    MX mx.example.com
    www CNAME www.example.com
    Without specifying
    A 11.22.33.444
    (I am pretty sure this is *technically* allowed, but is it really OK to do or are there reasons not to do this?)
    --
    And there were all the stars, looking remarkably like powered
    diamonds spilled on black velvet, the stars that lured and
    ultimately called the boldest towards them…
    --- Synchronet 3.18a-Linux NewsLink 1.113
  • From Anand Buddhdev@anandb@ripe.net to @lbutlr on Thu Jul 9 14:43:04 2020
    From Newsgroup: comp.protocols.dns.bind

    On 09/07/2020 14:21, @lbutlr wrote:

    Given a domain that is hosted and used for email and web, is an A
    record for that domain actually required?

    It's not *required*. But see below.

    That is, if bob.tld is hosted by example.com can you simply have

    NS ns1.example.com
    NS ns2.example.com
    MX mx.example.com

    www CNAME www.example.com

    Without specifying

    A 11.22.33.444

    These days, many folk try to reach websites by typing just the bare
    domain name without the "www" prefix.

    If a user types "bob.tld" into a browser, the browser will issue an
    address lookup for "bob.tld", causing the resolver to ask for A and AAAA records for "bob.tld". If you don't have an A record at the zone apex,
    the browser will not get back any address and display an error message
    for the user. An alert user might try "www.bob.tld" but most users are
    likely to just give up.

    So while it's not *required* to have an address record at the apex, it's
    good practice to have one.

    Anand
    --- Synchronet 3.18a-Linux NewsLink 1.113
  • From Mark Andrews@marka@isc.org to @lbutlr on Thu Jul 9 22:55:48 2020
    From Newsgroup: comp.protocols.dns.bind

    At this stage one still needs A records to be reachable by everyone. One should also ensure you are reachable over IPv6 as lots of the world behind IPv6 only links as their ISPs don’t have enough IPv4 addresses for every one. Instead they have to use some form of IPv4 as a service which is significantly more expensive to operate compared to straight routers.
    --
    Mark Andrews
    On 9 Jul 2020, at 22:22, @lbutlr <kremels@kreme.com> wrote:

    Given a domain that is hosted and used for email and web, is an A record for that domain actually required?

    That is, if bob.tld is hosted by example.com can you simply have

    NS ns1.example.com
    NS ns2.example.com
    MX mx.example.com

    www CNAME www.example.com

    Without specifying

    A 11.22.33.444

    (I am pretty sure this is *technically* allowed, but is it really OK to do or are there reasons not to do this?)



    --
    And there were all the stars, looking remarkably like powered
    diamonds spilled on black velvet, the stars that lured and
    ultimately called the boldest towards them…

    _______________________________________________
    Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

    ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.


    bind-users mailing list
    bind-users@lists.isc.org
    https://lists.isc.org/mailman/listinfo/bind-users
    --- Synchronet 3.18a-Linux NewsLink 1.113
  • From Matthew Richardson@matthew-l@itconsult.co.uk to bind-users on Thu Jul 9 15:06:27 2020
    From Newsgroup: comp.protocols.dns.bind

    On a related issues there were (perhaps long ago) issues if the A record
    for a domain had an SMTP server on it, where email could sometimes be
    delivered to that A record rather than the MX. I had (again long ago:
    10-15 years) actually seen this occur.

    Do people think that this problem could still occur these days? What sort
    of transient (presumably DNS) failure might cause an SMTP server to deliver
    to A rather than MX?

    Best wishes,
    Matthew

    ------
    From: Anand Buddhdev <anandb@ripe.net>
    To: "@lbutlr" <kremels@kreme.com>, bind-users <bind-users@lists.isc.org>
    Cc:
    Date: Thu, 9 Jul 2020 14:43:04 +0200
    Subject: Re: Dumb Question is an A or AAAA record required?

    On 09/07/2020 14:21, @lbutlr wrote:

    Given a domain that is hosted and used for email and web, is an A
    record for that domain actually required?

    It's not *required*. But see below.

    That is, if bob.tld is hosted by example.com can you simply have

    NS ns1.example.com
    NS ns2.example.com
    MX mx.example.com

    www CNAME www.example.com

    Without specifying

    A 11.22.33.444

    These days, many folk try to reach websites by typing just the bare
    domain name without the "www" prefix.

    If a user types "bob.tld" into a browser, the browser will issue an
    address lookup for "bob.tld", causing the resolver to ask for A and AAAA >records for "bob.tld". If you don't have an A record at the zone apex,
    the browser will not get back any address and display an error message
    for the user. An alert user might try "www.bob.tld" but most users are >likely to just give up.

    So while it's not *required* to have an address record at the apex, it's >good practice to have one.

    Anand
    _______________________________________________
    Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

    ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.


    bind-users mailing list
    bind-users@lists.isc.org
    https://lists.isc.org/mailman/listinfo/bind-users

    --- Synchronet 3.18a-Linux NewsLink 1.113
  • From =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?=@ondrej@isc.org to Matthew Richardson on Thu Jul 9 16:10:09 2020
    From Newsgroup: comp.protocols.dns.bind

    Missing MX, there’s actually syntax accepted by major SMTP servers to disable SMTP for domain:
    example.com. MX 0 .
    Ondrej
    --
    Ondřej Surý — ISC
    On 9 Jul 2020, at 16:06, Matthew Richardson <matthew-l@itconsult.co.uk> wrote:

    On a related issues there were (perhaps long ago) issues if the A record for a domain had an SMTP server on it, where email could sometimes be delivered to that A record rather than the MX. I had (again long ago:
    10-15 years) actually seen this occur.

    Do people think that this problem could still occur these days? What sort> of transient (presumably DNS) failure might cause an SMTP server to deliver
    to A rather than MX?

    Best wishes,
    Matthew

    ------
    From: Anand Buddhdev <anandb@ripe.net>
    To: "@lbutlr" <kremels@kreme.com>, bind-users <bind-users@lists.isc.org>
    Cc:
    Date: Thu, 9 Jul 2020 14:43:04 +0200
    Subject: Re: Dumb Question is an A or AAAA record required?

    On 09/07/2020 14:21, @lbutlr wrote:

    Given a domain that is hosted and used for email and web, is an A
    record for that domain actually required?

    It's not *required*. But see below.

    That is, if bob.tld is hosted by example.com can you simply have

    NS ns1.example.com
    NS ns2.example.com
    MX mx.example.com

    www CNAME www.example.com

    Without specifying

    A 11.22.33.444

    These days, many folk try to reach websites by typing just the bare
    domain name without the "www" prefix.

    If a user types "bob.tld" into a browser, the browser will issue an
    address lookup for "bob.tld", causing the resolver to ask for A and AAAA >> records for "bob.tld". If you don't have an A record at the zone apex, >> the browser will not get back any address and display an error message >> for the user. An alert user might try "www.bob.tld" but most users are >> likely to just give up.

    So while it's not *required* to have an address record at the apex, it's >> good practice to have one.

    Anand
    _______________________________________________
    Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

    ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.


    bind-users mailing list
    bind-users@lists.isc.org
    https://lists.isc.org/mailman/listinfo/bind-users

    _______________________________________________
    Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

    ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.


    bind-users mailing list
    bind-users@lists.isc.org
    https://lists.isc.org/mailman/listinfo/bind-users
    --- Synchronet 3.18a-Linux NewsLink 1.113
  • From Matus UHLAR - fantomas@uhlar@fantomas.sk to bind-users on Thu Jul 9 16:24:38 2020
    From Newsgroup: comp.protocols.dns.bind

    On 09.07.20 15:06, Matthew Richardson wrote:
    On a related issues there were (perhaps long ago) issues if the A record
    for a domain had an SMTP server on it, where email could sometimes be >delivered to that A record rather than the MX. I had (again long ago:
    10-15 years) actually seen this occur.

    If there is MX record for a domain, a MTA MUST only use MX record when delivering to that domain.

    If there is no MX record for a domain, but an A record is available, MTA
    uses default MX with preference of 0 pointing to that A records.

    This is how it's defined to work, this is not "an issue about that".

    Do people think that this problem could still occur these days? What sort
    of transient (presumably DNS) failure might cause an SMTP server to deliver >to A rather than MX?

    the only DNS failure that could cause this (and I can think of now) is if
    DNS server incorrectly returned NODATA for MX record (effectively saying there's no MX).

    --
    Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/
    Warning: I wish NOT to receive e-mail advertising to this address.
    Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
    Spam = (S)tupid (P)eople's (A)dvertising (M)ethod
    --- Synchronet 3.18a-Linux NewsLink 1.113
  • From Anand Buddhdev@anandb@ripe.net to Matthew Richardson on Thu Jul 9 17:06:13 2020
    From Newsgroup: comp.protocols.dns.bind

    On 09/07/2020 16:06, Matthew Richardson wrote:

    On a related issues there were (perhaps long ago) issues if the A record
    for a domain had an SMTP server on it, where email could sometimes be delivered to that A record rather than the MX. I had (again long ago:
    10-15 years) actually seen this occur.

    Note that *delivery* will only happen if that A record were actually
    listening on tcp/25 and accepting SMTP connections. No-one should be
    opening up the SMTP port on a server meant to serve only HTTP(S)
    traffic. Anyone who does that deserves what they get for making such
    poor decisions.

    Anand
    --- Synchronet 3.18a-Linux NewsLink 1.113
  • From Matthew Richardson@matthew-l@itconsult.co.uk to bind-users on Thu Jul 9 17:03:01 2020
    From Newsgroup: comp.protocols.dns.bind

    My question is raised because of such "poor decisions" by certain web
    hosting providers (naming no names!) whose provisioning systems require
    records for both www and the domain root pointing to their systems, and
    where those systems DO LISTEN on port 25.

    In these modern days, should one be concerned about this for a domain where
    the MX records point to proper enterprise grade email services? The
    problem is that the web hosting provider's poor decision might interfere
    with the enterprise email system.

    I think Matus may be correct that this is only an issue if the MX query
    returns NODATA rather than timing out. In the old days (10-15 years ago),
    I think a timeout may have triggered the failback from MX to A, but I am
    not sure.

    Best wishes,
    Matthew

    ------
    From: Anand Buddhdev <anandb@ripe.net>
    To: Matthew Richardson <matthew-l@itconsult.co.uk>, bind-users <bind-users@lists.isc.org>
    Cc:
    Date: Thu, 9 Jul 2020 17:06:13 +0200
    Subject: Re: Dumb Question is an A or AAAA record required?

    On 09/07/2020 16:06, Matthew Richardson wrote:

    On a related issues there were (perhaps long ago) issues if the A record
    for a domain had an SMTP server on it, where email could sometimes be
    delivered to that A record rather than the MX. I had (again long ago:
    10-15 years) actually seen this occur.

    Note that *delivery* will only happen if that A record were actually >listening on tcp/25 and accepting SMTP connections. No-one should be
    opening up the SMTP port on a server meant to serve only HTTP(S)
    traffic. Anyone who does that deserves what they get for making such
    poor decisions.

    Anand

    --- Synchronet 3.18a-Linux NewsLink 1.113
  • From Mark Andrews@marka@isc.org to Matthew Richardson on Fri Jul 10 05:32:59 2020
    From Newsgroup: comp.protocols.dns.bind

    Very soon you will be able to specify HTTPS records. BIND has a implementation that is just waiting for the draft to go to the RFC editor. The type codes are already allocated.
    This still requires clients to lookup the records but the browser vendors are on board.
    --
    Mark Andrews
    On 10 Jul 2020, at 02:03, Matthew Richardson <matthew-l@itconsult.co.uk> wrote:

    My question is raised because of such "poor decisions" by certain web hosting providers (naming no names!) whose provisioning systems require records for both www and the domain root pointing to their systems, and
    where those systems DO LISTEN on port 25.

    In these modern days, should one be concerned about this for a domain where the MX records point to proper enterprise grade email services? The
    problem is that the web hosting provider's poor decision might interfere
    with the enterprise email system.

    I think Matus may be correct that this is only an issue if the MX query returns NODATA rather than timing out. In the old days (10-15 years ago),> I think a timeout may have triggered the failback from MX to A, but I am
    not sure.

    Best wishes,
    Matthew

    ------
    From: Anand Buddhdev <anandb@ripe.net>
    To: Matthew Richardson <matthew-l@itconsult.co.uk>, bind-users <bind-users@lists.isc.org>
    Cc:
    Date: Thu, 9 Jul 2020 17:06:13 +0200
    Subject: Re: Dumb Question is an A or AAAA record required?

    On 09/07/2020 16:06, Matthew Richardson wrote:
    On a related issues there were (perhaps long ago) issues if the A record>>> for a domain had an SMTP server on it, where email could sometimes be
    delivered to that A record rather than the MX. I had (again long ago:
    10-15 years) actually seen this occur.
    Note that *delivery* will only happen if that A record were actually
    listening on tcp/25 and accepting SMTP connections. No-one should be
    opening up the SMTP port on a server meant to serve only HTTP(S)
    traffic. Anyone who does that deserves what they get for making such
    poor decisions.
    Anand

    _______________________________________________
    Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

    ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.


    bind-users mailing list
    bind-users@lists.isc.org
    https://lists.isc.org/mailman/listinfo/bind-users
    --- Synchronet 3.18a-Linux NewsLink 1.113
  • From Grant Taylor@gtaylor@tnetconsulting.net to bind-users on Thu Jul 9 22:25:43 2020
    From Newsgroup: comp.protocols.dns.bind

    This is a cryptographically signed message in MIME format.

    --------------ms000409060305070506010908
    Content-Type: text/plain; charset=utf-8; format=flowed
    Content-Language: en-US
    Content-Transfer-Encoding: quoted-printable

    On 7/9/20 6:43 AM, Anand Buddhdev wrote:
    If you don't have an A record at the zone apex, the browser will not=20
    get back any address and display an error message for the user.

    There was a point in time when the big web browsers would try connecting =

    to www.<domain>.<tld> if connecting to <domain>.<tld> failed.

    I don't know what the current state of affairs is.



    --=20
    Grant. . . .
    unix || die


    --------------ms000409060305070506010908
    Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64
    Content-Disposition: attachment; filename="smime.p7s"
    Content-Description: S/MIME Cryptographic Signature

    MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CzkwggUhMIIECaADAgECAhA53zcXtFD9dENby64EqrKqMA0GCSqGSIb3DQEBCwUAMIGWMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTE5MTExOTAwMDAw MFoXDTIwMTExODIzNTk1OVowKzEpMCcGCSqGSIb3DQEJARYaZ3RheWxvckB0bmV0Y29uc3Vs dGluZy5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCwIZcEJcuE7mUfxJnD I8oOSX/TvAhoP11agD++8L7Ok8fFJhJK0lOVRsq1M6lF2E2Vzuyffg2ppbecWvHcIRadsaiG imnrJQasdkhj/JUtqPUXnC0SVA0AzYLrLReQB+9j/jTgB5JnFLyC2lEn9KTA6JmDGjvVkv2T k+I2+v24nI4/2lGjD+jIKQiFXkE1uqablXJAw1c9Mh9d4/wjnIM9zLGv1i3xxOLdQ1PXSUZL 12wOy1r7CsGAnNSNhGaceB2tdhdleFEyIHgSgDWtWResHdu/ubZqFiHxaLRJlafOHMj3yC6x NOA1IdcNJsaRkQHxSkayKzeE5JK3TxlV83dbAgMBAAGjggHTMIIBzzAfBgNVHSMEGDAWgBQJ wPL8C9qU21/+K9+omULPyeCtADAdBgNVHQ4EFgQUU6bXebmKM+efFHN0MBjYuJO9Za8wDgYD VR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUF BwMCMEAGA1UdIAQ5MDcwNQYMKwYBBAGyMQECAQEBMCUwIwYIKwYBBQUHAgEWF2h0dHBzOi8v c2VjdGlnby5jb20vQ1BTMFoGA1UdHwRTMFEwT6BNoEuGSWh0dHA6Ly9jcmwuc2VjdGlnby5j b20vU2VjdGlnb1JTQUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmww gYoGCCsGAQUFBwEBBH4wfDBVBggrBgEFBQcwAoZJaHR0cDovL2NydC5zZWN0aWdvLmNvbS9T ZWN0aWdvUlNBQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAjBggr BgEFBQcwAYYXaHR0cDovL29jc3Auc2VjdGlnby5jb20wJQYDVR0RBB4wHIEaZ3RheWxvckB0 bmV0Y29uc3VsdGluZy5uZXQwDQYJKoZIhvcNAQELBQADggEBADOWdJFXVQvdVPUy4ChriEyS 3wiEdWmLb3CGko4ps7uXgHoCk0V9oU38LjKTrcm/KOhLhBh2Wz3LxirbtgTP+YxpgkPxDEWO ee/o/TiLhVrTLiqZJIwjlZmY1lTmHuoXWQK3M0MJZYVrGgMJgQg0/+mZkRlEa67N4WETh7MH rKglv3HHy3LeU835KA8cpMxRbDvPiA8wdKHWgrl4LXOJKtI8rgmMJxUOCQdgI6DSEo/yYve0 /TxLLBlWAhve7e+/aYjKn3V5CpNOmqkRi7V2d6ZJ+RMQrJDtqitQAkzq8cH+CSTGagHzAxQp e00hH+aVwNioyaoNBezCCLirOjVdlFIwggYQMIID+KADAgECAhBNlCwQ1DvglAnFgS06KwZP MA0GCSqGSIb3DQEBDAUAMIGIMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEU MBIGA1UEBxMLSmVyc2V5IENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEu MCwGA1UEAxMlVVNFUlRydXN0IFJTQSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0xODEx MDIwMDAwMDBaFw0zMDEyMzEyMzU5NTlaMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3Jl YXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExp bWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg U2VjdXJlIEVtYWlsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyjztlApB /975Rrno1jvm2pK/KxBOqhq8gr2+JhwpKirSzZxQgT9tlC7zl6hn1fXjSo5MqXUfItMltrMa XqcESJuK8dtK56NCSrq4iDKaKq9NxOXFmqXX2zN8HHGjQ2b2Xv0v1L5Nk1MQPKA19xeWQcpG EGFUUd0kN+oHox+L9aV1rjfNiCj3bJk6kJaOPabPi2503nn/ITX5e8WfPnGw4VuZ79Khj1YB rf24k5Ee1sLTHsLtpiK9OjG4iQRBdq6Z/TlVx/hGAez5h36bBJMxqdHLpdwIUkTqT8se3ed0 PewDch/8kHPo5fZl5u1B0ecpq/sDN/5sCG52Ds+QU5O5EwIDAQABo4IBZDCCAWAwHwYDVR0j BBgwFoAUU3m/WqorSs9UgOHYm8Cd8rIDZsswHQYDVR0OBBYEFAnA8vwL2pTbX/4r36iZQs/J 4K0AMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdJQQWMBQGCCsG AQUFBwMCBggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwUAYDVR0fBEkwRzBFoEOgQYY/ aHR0cDovL2NybC51c2VydHJ1c3QuY29tL1VTRVJUcnVzdFJTQUNlcnRpZmljYXRpb25BdXRo b3JpdHkuY3JsMHYGCCsGAQUFBwEBBGowaDA/BggrBgEFBQcwAoYzaHR0cDovL2NydC51c2Vy dHJ1c3QuY29tL1VTRVJUcnVzdFJTQUFkZFRydXN0Q0EuY3J0MCUGCCsGAQUFBzABhhlodHRw Oi8vb2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBDAUAA4ICAQBBRHUAqznCFfXejpVt MnFojADdF9d6HBA4kMjjsb0XMZHztuOCtKF+xswhh2GqkW5JQrM8zVlU+A2VP72Ky2nlRA1G wmIPgou74TZ/XTarHG8zdMSgaDrkVYzz1g3nIVO9IHk96VwsacIvBF8JfqIs+8aWH2PfSUrN xP6Ys7U0sZYx4rXD6+cqFq/ZW5BUfClN/rhk2ddQXyn7kkmka2RQb9d90nmNHdgKrwfQ49mQ 2hWQNDkJJIXwKjYA6VUR/fZUFeCUisdDe/0ABLTI+jheXUV1eoYV7lNwNBKpeHdNuO6Aacb5 33JlfeUHxvBz9OfYWUiXu09sMAviM11Q0DuMZ5760CdO2VnpsXP4KxaYIhvqPqUMWqRdWyn7 crItNkZeroXaecG03i3mM7dkiPaCkgocBg0EBYsbZDZ8bsG3a08LwEsL1Ygz3SBsyECa0waq 4hOf/Z85F2w2ZpXfP+w8q4ifwO90SGZZV+HR/Jh6rEaVPDRF/CEGVqR1hiuQOZ1YL5ezMTX0 ZSLwrymUE0pwi/KDaiYB15uswgeIAcA6JzPFf9pLkAFFWs1QNyN++niFhsM47qodx/PL+5jR 87myx5uYdBEQkkDc+lKB1Wct6ucXqm2EmsaQ0M95QjTmy+rDWjkDYdw3Ms6mSWE3Bn7i5Zgt wCLXgAIe5W8mybM2JzGCBDIwggQuAgEBMIGrMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMS R3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdv IExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBh bmQgU2VjdXJlIEVtYWlsIENBAhA53zcXtFD9dENby64EqrKqMA0GCWCGSAFlAwQCAQUAoIIC VzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDA3MTAwNDI1 NDNaMC8GCSqGSIb3DQEJBDEiBCCEHM4yInU+AA8NeOtoAA0neopnpDIQFuwMkHAgAgvqXzBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIG8BgkrBgEEAYI3EAQxga4wgaswgZYxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRl ZDE+MDwGA1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1 cmUgRW1haWwgQ0ECEDnfNxe0UP10Q1vLrgSqsqowgb4GCyqGSIb3DQEJEAILMYGuoIGrMIGW MQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdT YWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNB IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhA53zcXtFD9dENb y64EqrKqMA0GCSqGSIb3DQEBAQUABIIBAD3h0F6hzLtsr5baJj/UvMhSIPArE48rWOBpMMyd hhl8ZfnJsskQNgx8BuWgz0kueAQP8MwC8kOuA8cJyKI0hQa0NcUmo8IekKeu9MBwqQzlKndn ghQ7Tb9G4P1ePuCZ4AZNMcvEeUakRevx2wh30sbF/siV3+6vlqti0HMAreD8HjWIcHpHgXSK rCkcL9kVC8rNHyGLyumv+4OybRtaMBaKN3VA/vZnx2M8eZAZWlOeh/t/xxzqu8szgLUHMc6R SL8w0u7puPCuk4EeLdPAEj/PAprQqC+6IRToLnFXQiDj9stKVdG8xANFc8RKqwa4iuhKbaQ7 CqsZaQq/HoIFPjwAAAAAAAA=
    --------------ms000409060305070506010908--
    --- Synchronet 3.18a-Linux NewsLink 1.113