"tragic" : port 2642 info requested - TCP-IP

This is a discussion on "tragic" : port 2642 info requested - TCP-IP ; hi folks, during the course of my research i faced a problem and was wondering if you could help me with that. I am trying to find some/any info about what is the application - "tragic" thats associated with port ...

+ Reply to Thread
Results 1 to 17 of 17

Thread: "tragic" : port 2642 info requested

  1. "tragic" : port 2642 info requested

    hi folks,

    during the course of my research i faced a problem and was wondering
    if you could help me with that.

    I am trying to find some/any info about what is the application -
    "tragic" thats associated with port 2642. there is a lot of data from
    the TCP dump that i saw and i had no clue on what that application is.

    i have tried to look it up on Google and a few books a LOT, but with
    no avail.

    can you help ?

    thanks in advance
    rohit

  2. Re: "tragic" : port 2642 info requested

    On 8 Aug 2003 22:26:13 -0700, razdanrohit@yahoo.com (Rohit) wrote:

    [follow-up set to comp.protocols.tcp-ip]


    >I am trying to find some/any info about what is the application -
    >"tragic" thats associated with port 2642. there is a lot of data from
    >the TCP dump that i saw and i had no clue on what that application is.
    >i have tried to look it up on Google and a few books a LOT, but with
    >no avail.


    How do you know the application that's using port 2642 is called
    "tragic"?

    --
    Fernando Gont
    e-mail: fernando@ANTISPAM.gont.com.ar

    [To send a personal reply, please remove the ANTISPAM tag]

  3. Re: "tragic" : port 2642 info requested

    On 9 Aug 2003 10:59:21 -0700, razdanrohit@yahoo.com (Rohit) wrote:

    >thanks for the reply. i got this information from the TCP dump data
    >that we recieved.
    >if you look up "tragic 2642" in google, it gives some results.. so it
    >does exist at the very least


    I think the information you got from tcpdump is just that someone is
    using port 2642. If it's being used as the source port, then nothing's
    strange with it.

    If it's being used as the destination port, in
    http://www.iana.org/assinments/port-numbers
    you can find:

    tragic 2642/tcp Tragic
    tragic 2642/udp Tragic
    # Stu Mark

    (I've added the ".REMOVE" to protect Mark's e-mail address from
    spammers)

    So you may mail Stu Mark and ask him about "tragic", or visit
    http://www.j51.com, and see if that site has any information related
    to "tragic" (the "www.j51.com" web site could just as well have no
    relation with "tragic", though).

    --
    Fernando Gont
    e-mail: fernando@ANTISPAM.gont.com.ar

    [To send a personal reply, please remove the ANTISPAM tag]

  4. How not to obfuscate mailbox names

    FG> # Stu Mark
    FG> (I've added the ".REMOVE" to protect Mark's e-mail address
    FG> from spammers)

    It's good practice to add the invalid label as the top-level domain, so that
    query resolution for the domain stops with a "no such name" error as early
    as possible in the process, thereby reducing DNS traffic.

    For "j51.REMOVETHISLABEL.com.", query resolution involves traffic to and from
    both the "." content DNS servers and the "com." content DNS servers before a
    complete answer is obtained. In contrast: For "j51.com.REMOVETHISLABEL.",
    query resolution only involves traffic to and from the "." content DNS
    servers.

    Ironically, your obfuscation is also deficient in a _second_ way.
    "j51.REMOVE.com." is a domain name that _actually exists_. So not only will
    the senders of unsolicited bulk mail generate DNS traffic to and from _three_
    sets of content DNS servers (the ".", "com.", and "remove.com." content DNS
    servers), they will also hammer the poor SMTP Relay server at 66.33.40.21 with
    SMTP Relay traffic.

    FG> e-mail: fernando@ANTISPAM.gont.com.ar

    Another case in point. Again, all of the enclosing superdomains and the
    domain name itself exist. The senders of unsolicited bulk mail will
    potentially generate DNS traffic to and from _four_ sets of content DNS
    servers (the ".", "ar.", "com.ar.", and "gont.com.ar." content DNS servers)
    when performing query resolution to look up the "MX"/"A" resource record sets;
    and they will hammer the SMTP Relay servers at 66.150.161.133, 66.150.161.134,
    66.150.161.135, and 66.150.161.136 with the SMTP Relay traffic.

  5. Re: How not to obfuscate mailbox names


    "Jonathan de Boyne Pollard" wrote in message
    news:3F659420.8C1C0193@Tesco.NET...
    > FG> # Stu Mark
    > FG> (I've added the ".REMOVE" to protect Mark's e-mail address
    > FG> from spammers)
    >
    > It's good practice to add the invalid label as the top-level domain, so

    that
    > query resolution for the domain stops with a "no such name" error as early
    > as possible in the process, thereby reducing DNS traffic.


    Shouldn't someone then create a TLD for INVALID, and standardize this
    practice?

    -- glen



  6. Re: How not to obfuscate mailbox names

    In article <3F659420.8C1C0193@Tesco.NET>,
    Jonathan de Boyne Pollard wrote:
    >FG> # Stu Mark
    >FG> (I've added the ".REMOVE" to protect Mark's e-mail address
    >FG> from spammers)
    >
    >It's good practice to add the invalid label as the top-level domain, so that
    >query resolution for the domain stops with a "no such name" error as early
    >as possible in the process, thereby reducing DNS traffic.
    >
    >For "j51.REMOVETHISLABEL.com.", query resolution involves traffic to and from
    >both the "." content DNS servers and the "com." content DNS servers before a


    You'd sorta hope his DNS server has cached where the .com nameservers are, no ?
    --
    OEM parts - Benz: http://parts.mbz.org BMW: http://buyeuroparts.com
    http://www.mbz.org | Mailing lists: http://lists.mbz.org
    633CSi 250SE/C 300SD | Classifieds: http://ads.mbz.org
    2 X 280SE | Wrist Watch list: http://watches.list.mbz.org

  7. Re: How not to obfuscate mailbox names

    In article ,
    Glen Herrmannsfeldt wrote:
    >
    >"Jonathan de Boyne Pollard" wrote in message
    >news:3F659420.8C1C0193@Tesco.NET...
    >> FG> # Stu Mark
    >> FG> (I've added the ".REMOVE" to protect Mark's e-mail address
    >> FG> from spammers)
    >>
    >> It's good practice to add the invalid label as the top-level domain, so

    >that
    >> query resolution for the domain stops with a "no such name" error as early
    >> as possible in the process, thereby reducing DNS traffic.

    >
    >Shouldn't someone then create a TLD for INVALID, and standardize this
    >practice?


    Then what are the invalids supposed to use? Arf arf.

    What would you want the .invalid tld to do? Point someplace?
    Wildcard everything to localhost?

    There is an RFC that defines tlds like this, I don't know the
    number offhand, but it's (I think) the one that defines
    (I think) .example and a few others as reserved names
    that are never to be implemented, such as .invalid.

    Originally "a few others" numbered about 30 (including
    my suggestion of .bogus that I really liked) but
    it got cut back to about 6 or so (by, I think, Bill
    Manning).




    --
    OEM parts - Benz: http://parts.mbz.org BMW: http://buyeuroparts.com
    http://www.mbz.org | Mailing lists: http://lists.mbz.org
    633CSi 250SE/C 300SD | Classifieds: http://ads.mbz.org
    2 X 280SE | Wrist Watch list: http://watches.list.mbz.org

  8. Re: How not to obfuscate mailbox names

    Glen Herrmannsfeldt writes:

    >
    > "Jonathan de Boyne Pollard" wrote in message
    > news:3F659420.8C1C0193@Tesco.NET...
    >> FG> # Stu Mark
    >> FG> (I've added the ".REMOVE" to protect Mark's e-mail address
    >> FG> from spammers)
    >>
    >> It's good practice to add the invalid label as the top-level domain, so

    > that
    >> query resolution for the domain stops with a "no such name" error as early
    >> as possible in the process, thereby reducing DNS traffic.

    >
    > Shouldn't someone then create a TLD for INVALID, and standardize this
    > practice?


    .... And then the spamware will simply strip .invalid from harvested
    addresses.




    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.2.1 (GNU/Linux)

    iD8DBQA/Zj5Xx9p3GYHlUOIRAqvWAJsG4J5NEgLFyCQsicOjocWMLFvlnw CePfFH
    VOTxJ68vwGdwZ8mwlECTxk4=
    =TSJD
    -----END PGP SIGNATURE-----


  9. Re: How not to obfuscate mailbox names

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    In comp.mail.misc, you wrote:
    >
    > Glen Herrmannsfeldt writes:
    >
    >>
    >> "Jonathan de Boyne Pollard" wrote in message
    >> news:3F659420.8C1C0193@Tesco.NET...
    >>> FG> # Stu Mark
    >>> FG> (I've added the ".REMOVE" to protect Mark's e-mail address
    >>> FG> from spammers)
    >>>
    >>> It's good practice to add the invalid label as the top-level domain, so

    >> that
    >>> query resolution for the domain stops with a "no such name" error as early
    >>> as possible in the process, thereby reducing DNS traffic.

    >>
    >> Shouldn't someone then create a TLD for INVALID, and standardize this
    >> practice?

    >
    > ... And then the spamware will simply strip .invalid from harvested
    > addresses.
    >



    It won't, however, stop you from also adding spam-deflecting garbage in
    the middle of the address as well to deter harvesting...

    my 2 cents,
    Jeff


    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.2.1 (GNU/Linux)

    iD8DBQE/Zmptkj0fZ6ayy6ARAmCXAJ9VEpWpYgz+Rb7wgDYDj4oEwcXG1g CfSAiB
    TrOI/pcktPmIDiHy0maX2zw=
    =cpy2
    -----END PGP SIGNATURE-----

  10. Re: How not to obfuscate mailbox names

    Glen Herrmannsfeldt (gah@ugcs.caltech.edu) wrote:

    : Shouldn't someone then create a TLD for INVALID, and standardize this
    : practice?


    Wasn't this the purpose of example.com?

    Domain Name: EXAMPLE.COM
    Registrar: RESERVED-INTERNET ASSIGNED NUMBERS AUTHORITY
    Whois Server: whois.iana.org
    Referral URL: http://res-dom.iana.org
    Name Server: A.IANA-SERVERS.NET
    Name Server: B.IANA-SERVERS.NET
    Status: REGISTRY-LOCK
    Updated Date: 08-jan-2003
    Creation Date: 14-aug-1995
    Expiration Date: 13-aug-2011

    Always though that was considered a "valid" null address similar to the way
    192.168.1.x (and 10.x) was for internal netblocks.

    -bruce
    bje@ripco.com


  11. Re: How not to obfuscate mailbox names

    Bruce Esquibel wrote in message ...
    >Glen Herrmannsfeldt (gah@ugcs.caltech.edu) wrote:
    >
    >: Shouldn't someone then create a TLD for INVALID, and standardize this
    >: practice?
    >
    >
    >Wasn't this the purpose of example.com?

    [...]
    >Always thought that was considered a "valid" null address similar to the

    way
    >192.168.1.x (and 10.x) was for internal netblocks.



    There's a subtle difference between _example_ names and
    _invalid_ names.

    Groetjes,
    Maarten Wiltink




  12. Re: How not to obfuscate mailbox names

    "Bruce Esquibel" wrote in message
    news:bk74hk$j7c$1@e250.ripco.com

    > Wasn't this the purpose of example.com?

    [...]
    > Always though that was considered a "valid" null address similar to
    > the way 192.168.1.x (and 10.x) was for internal netblocks.


    $ ping example.com
    PING example.com (192.0.34.166) from w.x.y.z : 56(84) bytes of data.
    64 bytes from www.example.com (192.0.34.166): icmp_seq=0 ttl=48 time=557.716 msec
    64 bytes from www.example.com (192.0.34.166): icmp_seq=1 ttl=48 time=269.878 msec
    ....

    --
    use hotmail com for any email replies


    -----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
    http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
    -----== Over 100,000 Newsgroups - 19 Different Servers! =-----

  13. Re: How not to obfuscate mailbox names

    ynotssor ("ynotssor") wrote:

    : $ ping example.com
    : PING example.com (192.0.34.166) from w.x.y.z : 56(84) bytes of data.
    : 64 bytes from www.example.com (192.0.34.166): icmp_seq=0 ttl=48 time=557.716 msec
    : 64 bytes from www.example.com (192.0.34.166): icmp_seq=1 ttl=48 time=269.878 msec
    : ...


    http://www.rfc-editor.org/rfc/rfc2606.txt

    -bruce
    bje@ripco.com

  14. Re: How not to obfuscate mailbox names


    "Richard J. Sexton (At work)" wrote in message
    news:HL9vM6.EKs@T-FCN.Net...
    > In article ,
    > Glen Herrmannsfeldt wrote:
    > >
    > >"Jonathan de Boyne Pollard" wrote in message
    > >news:3F659420.8C1C0193@Tesco.NET...
    > >> FG> # Stu Mark
    > >> FG> (I've added the ".REMOVE" to protect Mark's e-mail address
    > >> FG> from spammers)
    > >>
    > >> It's good practice to add the invalid label as the top-level domain, so

    > >that
    > >> query resolution for the domain stops with a "no such name" error as

    early
    > >> as possible in the process, thereby reducing DNS traffic.

    > >
    > >Shouldn't someone then create a TLD for INVALID, and standardize this
    > >practice?

    >
    > Then what are the invalids supposed to use? Arf arf.
    >
    > What would you want the .invalid tld to do? Point someplace?
    > Wildcard everything to localhost?


    (snip)

    I am not sure of the current status of negative caching. If it really
    works, then maybe it doesn't matter.

    If an INVALID TLD existed, then other servers would cache it. It could be
    made to NS to a specific server somewhere, other than the root servers, so
    that requests would go there. An A pointing to 127.1, and a matching MX,
    would at least make individual mail servers responsible for the results. No
    records at all would give NXDOMAIN for any requests, which servers may or
    may not understand what to do with.

    Is it worthwhile to get the load off the root servers?

    -- glen



  15. Re: How not to obfuscate mailbox names

    >If an INVALID TLD existed, then other servers would cache it. It could be
    >made to NS to a specific server somewhere, other than the root servers, so
    >that requests would go there. An A pointing to 127.1, and a matching MX,
    >would at least make individual mail servers responsible for the results. No
    >records at all would give NXDOMAIN for any requests, which servers may or
    >may not understand what to do with.
    >
    >Is it worthwhile to get the load off the root servers?


    No.

    Have a look at the crap the root servers put up with. This is the
    least of their problems.

    Deploy .invalid locally and see if it does what you want.



    --
    OEM parts - Benz: http://parts.mbz.org BMW: http://buyeuroparts.com
    http://www.mbz.org | Mailing lists: http://lists.mbz.org
    633CSi 250SE/C 300SD | Classifieds: http://ads.mbz.org
    2 X 280SE | Wrist Watch list: http://watches.list.mbz.org

  16. Re: How not to obfuscate mailbox names

    FG> # Stu Mark
    FG> (I've added the ".REMOVE" to protect Mark's e-mail address
    FG> from spammers)

    JdeBP> It's good practice to add the invalid label as the top-level
    JdeBP> domain, so that query resolution for the domain stops with a
    JdeBP> "no such name" error as early as possible in the process,
    JdeBP> thereby reducing DNS traffic.
    JdeBP> [...]

    GH> Shouldn't someone then create a TLD for INVALID, and
    GH> standardize this practice?

    I wasn't talking about the literal label "invalid". I was talking about an
    invalid label. In the examples that I gave, immediately following the text
    that you quote, the invalid label was "REMOVETHISLABEL".

  17. Re: How not to obfuscate mailbox names

    JdeBP> For "j51.REMOVETHISLABEL.com.", query resolution involves
    JdeBP> traffic to and from both the "." content DNS servers and the
    JdeBP> "com." content DNS servers before a complete answer is
    JdeBP> obtained. In contrast: For "j51.com.REMOVETHISLABEL.",
    JdeBP> query resolution only involves traffic to and from the "."
    JdeBP> content DNS servers.
    JdeBP>
    JdeBP> Ironically, your obfuscation is also deficient in a _second_
    JdeBP> way. "j51.REMOVE.com." is a domain name that _actually
    JdeBP> exists_. So not only will the senders of unsolicited bulk mail
    JdeBP> generate DNS traffic to and from _three_ sets of content DNS
    JdeBP> servers (the ".", "com.", and "remove.com." content DNS
    JdeBP> servers), they will also hammer the poor SMTP Relay server at
    JdeBP> 66.33.40.21 with SMTP Relay traffic.

    RJS> You'd sorta hope his DNS server has cached where the
    RJS> .com nameservers are, no ?

    That information does expire regularly, though. At which point, one is back
    querying the "." content DNS servers again. This is still more DNS traffic
    (generated by the senders of unsolicited bulk mail) than the case where query
    resolution stops at the "." content DNS servers. In the latter case, every
    cache miss involves querying _exactly one_ set of content DNS servers; whereas
    in the former case every cache miss involves querying _at least one_ set of
    content DNS servers, and sometimes two.

    But how ironic that you should post this on the very day of Verisign's land
    grab! Now, after the land grab, the situation has changed, and there are now
    other gains to be had that balance out the fact of the higher levels of
    traffic generated by the UBM senders.

    However, employing the invalid label as a subdomain of "com." _is_, still, the
    higher traffic option. Whatever invalid label one may choose as the "com."
    subdomain, the senders of unsolicited bulk mail will generate DNS traffic to
    and from two sets of content DNS servers (the "." and "com." content DNS
    servers), and will also hammer the (not necessarily poor, certainly broken,
    and arguably wholly deserving) SMTP Relay server at 64.94.110.11 with SMTP
    Relay traffic. This is still more traffic than the case with an invalid
    top-level domain, where no SMTP Relay server is hammered and where only one
    set of content DNS servers is queried.

+ Reply to Thread