Just how bad is this DNS-based spam-deviation scheme? - TCP-IP

This is a discussion on Just how bad is this DNS-based spam-deviation scheme? - TCP-IP ; I am getting as everybody else large spam messages, and I have a dialup connection, which makes it slightly more painful than otherwise needed. Like many others I use some spam countermeasures (like using suffixed local parts in email addresses ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: Just how bad is this DNS-based spam-deviation scheme?

  1. Just how bad is this DNS-based spam-deviation scheme?

    I am getting as everybody else large spam messages, and I have a dialup
    connection, which makes it slightly more painful than otherwise needed.

    Like many others I use some spam countermeasures (like using suffixed
    local parts in email addresses and 'bogofilter'). But these just help in
    tagging spam, _after_ I have downloaded it.

    I am considering switching for some purposes (e.g. News, mailing lists)
    to expiring email addresses, which become invalid after some
    weeks/months of their use. In this way I get hit with spam to a
    particular address only for a while, and hopefully the total level stays
    down.

    Using expiring local parts might seem OK, as I can just define most
    recent and still valid one as an alias in my MTA's configuration, and my
    MTA then rejects any local parts that are not known, including any
    expired ones; for example, for a seasonal expiration scheme:

    nameWinter03@example.org nameSpring03@example.org
    nameSummer03@example.org nameAutumn03@example.org

    However most of my mail goes to an ISP's mailbox from which I get it
    using 'fetchmail' via POP3, and this they would only be rejected by my
    MTA _after_ they have been downloaded on the dialup line.

    So I have been thinking about avoiding this altogether; by using
    expiring domain name parts instead of local parts. For example, for a
    seasonal expiration scheme:

    name@winter.2003.example.org name@spring.2003.example.org
    name@summer.2003.example.org name@autumn.2003.example.org

    and so on.

    The idea would be to MX those domain names, as they expire, to something
    that resolves to '127.0.0.1' or some other suitable ``get lost'' destination.
    and the current one to the approriate MTA interface (one can imagine
    several variations).

    Any technical or other reasons why this is not a good idea?

    Any suggestions?

  2. Re: Just how bad is this DNS-based spam-deviation scheme?

    >>> On Mon, 25 Aug 2003 20:10:45 GMT, Barry Margolin
    >>> said:


    barry.margolin> In article ,
    barry.margolin> Piercarlo Grandi wrote:

    >> So I have been thinking about avoiding this altogether; by using
    >> expiring domain name parts instead of local parts. For example, for a
    >> seasonal expiration scheme:
    >>
    >> name@winter.2003.example.org name@spring.2003.example.org
    >> name@summer.2003.example.org name@autumn.2003.example.org
    >>
    >> and so on.
    >>
    >> The idea would be to MX those domain names, as they expire, to
    >> something that resolves to '127.0.0.1' or some other suitable ``get
    >> lost'' destination. and the current one to the approriate MTA
    >> interface (one can imagine several variations).
    >>
    >> Any technical or other reasons why this is not a good idea?


    barry.margolin> This seems reasonable. You could probably do without
    barry.margolin> the "get lost" destination, and simply delete the DNS
    barry.margolin> entries for the expired domains.

    Good point, but I would like to have a wildcard MX on 'example.org',
    because it might be nice, except for the ``expiring'' domains, to use
    arbitrary subdomains of 'example.org' as specialized permanent
    addresses:

    barry.margolin> I presume you'll still have a permanent address that you
    barry.margolin> give out to regular correspondents. [ ... ]

    e.g. to give out addresses to track registrations or use for mailing
    lists, etc.:

    name@nytimes.reg.example.org
    name@kernel.list.example.org

    It has occurred to me is perhaps better than using local part suffixes
    as in:

    name+nytimes-reg@example.org
    name+kernel-list@example.org

    I am even thinking of having even more daring wildcard to expire whole
    ``years''...

    But then wildcard MX RRs are rightly considered quite risque`, but I
    suspect that this usage _might_ just work.

    So I would have something like:

    ------------------------------------------------------------------------
    $ORIGIN example.org
    $TTL 86400
    ;
    @ TXT "Zone for example.org"
    rp TXT "A. Name"
    ;@ RP root rp
    ;
    secure_zone TXT "10.0.0.0:255.0.0.0"
    ;
    @ SOA example.org. hostmaster.example.org. (
    ;serial refresh retry expire TTL
    2002110400 432000 3600 864000 86400
    )
    ;
    localhost A 127.0.0.1
    loopback PTR 127.In-addr.ARPA.
    ;
    @ NS ns
    @ NS ns2
    ; Wildcard alert
    * MX 1 SMTP
    *.2002 MX 10 localhost
    *.2003 MX 10 localhost
    autumn.2003 MX 10 SMTP
    ;
    net A 10.0.0.0
    net PTR 10.In-addr.ARPA.
    ;
    bc A 10.255.255.255
    sm A 255.0.0.0
    ;
    ns A 10.0.0.10
    ns2 A 10.0.0.11
    ;
    @ A 10.0.0.10
    ;
    SMTP A 10.0.0.10
    POP3 A 10.0.0.10
    ------------------------------------------------------------------------

    Again, one can imagine a number of variations.

  3. Re: Just how bad is this DNS-based spam-deviation scheme?

    PG> localhost A 127.0.0.1

    There is no actual need for this if you improve your "MX" resource record
    sets.

    PG> loopback PTR 127.In-addr.ARPA.

    What are you trying to achieve with this ?

    PG> *.2002 MX 10 localhost
    PG> *.2003 MX 10 localhost

    Use "localhost.", not "localhost".

    The actual reserved domain name with the pre-defined meaning is "localhost.",
    a top-level domain. The use, instead, of "localhost.example.org." results in
    an extra "A" lookup for that domain name reaching your content DNS servers,
    and extra traffic that isn't necessary. In contrast: Queries for
    "localhost." are, in order to address the issue described in RFC 1912, usually
    intercepted before they leave an organization.

    PG> * MX 1 SMTP

    If you are intending to feed this "zone" file to ISC's BIND, you should be
    aware that wildcard "MX" resource records only cover those domain names that
    don't actually exist. Wildcard "MX" resource records don't do what most
    people expect them to do. For completeness, you need to add to the database
    an explicit "MX" resource record for all of the existing domain names, such as
    "smtp.example.org.", individually.

    If you are intending to feed this "zone" file to Microsoft's DNS server, you
    can configure the software to employ an alternative wildcard mechnanism that
    _does_ do what most people (including you, going by what you write) expect
    wildcard "MX" resource records to do.

+ Reply to Thread