[OT] Odd spammer tactic? - SpamAssassin

This is a discussion on [OT] Odd spammer tactic? - SpamAssassin ; Bob McClure Jr wrote: > [snip] >> - delay (or block, depending on your implementation) good networks in >> case of DNS problems. (the dspam domain was once under DDoS. delaying >> their _sollicted_ mail is not really nice). > ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 31 of 31

Thread: [OT] Odd spammer tactic?

  1. Re: [OT] Odd spammer tactic?

    Bob McClure Jr wrote:
    > [snip]
    >> - delay (or block, depending on your implementation) good networks in
    >> case of DNS problems. (the dspam domain was once under DDoS. delaying
    >> their _sollicted_ mail is not really nice).

    >
    > Yeah, bummer. Maybe make an exception if DNS is unavailable, or soft
    > fail.
    >


    In this case, greylisting is safer.


    >>> Allow only those with MX records?

    >> if the envelope sender domain has no MX nor A record (or has an invalid
    >> or borked MX), you can block. but this doesn't catch much junk. It does
    >> however catch legitimate mail in case of misconfiguration.

    >
    > No, I don't mean that of the envelope sender - that means nothing. I
    > mean that the client machine must be listed as an MX. That said, yes,
    > I know, many installations (e.g. two of my clients) have separate IPs
    > for sending and receiving mail, so the sender is not listed as an MX.
    > And if it were so listed as a (secondary) MX and did not accept mail,
    > then it's busted for being a bogus MX. Never mind.
    >



    as you say, there is no reason for an "RMX" to be an MX, and there is no
    way to know whether an IP is an RMX (well, there is SPF, but let's not
    restart the old debate...).

    >>> I figure only the latter will be the Final Solution to spam.

    >> final what? fussp?
    >>
    >>
    >> since spammers forge the sender, sender checks don't buy you much.
    >>
    >>> But
    >>> there are probably only two chances of that - slim and none.

    >
    > Where is the Lone Ranger when you need him? (Silver bullet reference.)


    he went to buy some petrol for cheap


  2. Re: [OT] Odd spammer tactic?

    > On Tue, Jul 22, 2008 at 12:00 PM, Bob McClure Jr wrote:
    > > I figure only the latter will be the Final Solution to spam. But
    > > there are probably only two chances of that - slim and none.


    Guess which one are you?

    http://www.rhyolite.com/anti-spam/you-might-be.html

    On 22.07.08 16:01, Noel Jones wrote:
    > There isn't a Final Solution without replacing SMTP with something else,
    > and there is no agreement on what the "something else" should look like.
    > Likely it too would be exploited, but in new and interesting ways...


    and what about you?

    http://www.rhyolite.com/anti-spam/yo...#programmer-11


    --
    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.
    Enter any 12-digit prime number to continue.


  3. Re: [OT] Odd spammer tactic?

    Noel Jones wrote:
    > On Tue, Jul 22, 2008 at 12:00 PM, Bob McClure Jr > > wrote:
    >
    > If I may extend this OT thread, I'd like to know how draconian admins
    > get with their mail servers. Without considering RBLs, how much do
    > you limit client connections:
    >
    > Allow only those with (PTR and/or A) DNS records?
    >
    >
    > It's becoming common to reject clients with no PTR, but there are
    > still many legit hosts using an ISP that doesn't offer PTR. So this
    > is not universally acceptable and prone to false positives. This also
    > isn't terribly effective since many botted machines have proper DNS
    > entries.
    >
    > It would be nice if all ISP's firewalled port 25 and offered a
    > self-service interface so the customer could unblock it if they run a
    > server. 99% of customers would never notice that port 25 was blocked.
    >
    >

    Many do. That is why 587 is becoming popular for authenticated mail.
    Without it, many users would notice, as they would no longer be able to
    use their work's SMTP for those email addresses.

    Richard


  4. Re: [OT] Odd spammer tactic?

    Matus UHLAR - fantomas wrote:
    >> On Tue, Jul 22, 2008 at 12:00 PM, Bob McClure Jr wrote:
    >>> I figure only the latter will be the Final Solution to spam. But
    >>> there are probably only two chances of that - slim and none.

    >
    > Guess which one are you?
    >
    > http://www.rhyolite.com/anti-spam/you-might-be.html
    >
    > On 22.07.08 16:01, Noel Jones wrote:
    >> There isn't a Final Solution without replacing SMTP with something else,
    >> and there is no agreement on what the "something else" should look like.
    >> Likely it too would be exploited, but in new and interesting ways...

    >
    > and what about you?
    >
    > http://www.rhyolite.com/anti-spam/yo...#programmer-11
    >
    >



    The way I understand it, Noel meant that there are problems that are
    inherent to smtp, so you can't fix them without replacing smtp.

    anyway, for all what it's worth, rhyolite is not the bible. there are
    too many opinions and I'm happy with that, as long as people don't try
    to convince us that their way is the only one. Bomb Irak if that gets
    you elected, but count me out.


  5. Re: [OT] Odd spammer tactic?

    Am 2008-07-22 20:23:42, schrieb mouss:
    > There is one caveat in this argument. yes, an MTA would lookup the MX.
    > but it is the MX as seen in DNS, not as seen in _your_ zone.
    >
    > in short, if someone declares you as their MX (without your
    > authorization), you should not start listing clients that try to send
    > mail to such domains.


    Are there ANY leagal reasons to declare someons MX as there MX?
    Only the owner of a BOTNET would do this...

    > This is one problem with the MX "standard". anybody can list your
    > servers as their MX. there is no authorization mechanism.
    >
    > so when collecting such "anomalies", you need to do some checks before
    > listing the client. as a result, you need the "intended" recipient. in
    > which case, a real smtp daemon is the right choice.


    Thanks, Greetings and nice Day/Evening
    Michelle Konzack
    Systemadministrator
    24V Electronic Engineer
    Tamay Dogan Network
    Debian GNU/Linux Consultant


    --
    Linux-User #280138 with the Linux Counter, http://counter.li.org/
    ##################### Debian GNU/Linux Consultant #####################
    Michelle Konzack Apt. 917 ICQ #328449886
    +49/177/9351947 50, rue de Soultz MSN LinuxMichi
    +33/6/61925193 67100 Strasbourg/France IRC #Debian (irc.icq.com)

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

    iD8DBQFIiHcXC0FPBMSS+BIRAvxzAKCzYGtagYvTthNsis6NYy oxDXsnrgCgxPqS
    87GSb1t2zZ2g0I4G/fmrW5M=
    =fCjA
    -----END PGP SIGNATURE-----


  6. Re: [OT] Odd spammer tactic?

    Quoting Matus UHLAR - fantomas :

    >
    > On 24.07.08 14:35, Michelle Konzack wrote:
    >> Are there ANY leagal reasons to declare someons MX as there MX?

    >
    > Yes, a mistake, or a false assumption by ISP's client.


    We have DNS server sharing relationships with some of our biz
    partners. It gives us control over the DNS without having to horse
    around with ISPs that never get it right. So we all get free backup
    DNS.

    In one case that I know of, a friend of mine outsourced his DNS to a
    hosting provider just too be rid of the headache.


    jp
    --
    Framework? I don't need no steenking framework!

    ----------------------------------------------------------------
    @fferent Security Labs: Isolate/Insulate/Innovate
    http://www.afferentsecurity.com


  7. Re: [OT] Odd spammer tactic?

    > Am 2008-07-22 20:23:42, schrieb mouss:
    > > There is one caveat in this argument. yes, an MTA would lookup the MX.
    > > but it is the MX as seen in DNS, not as seen in _your_ zone.
    > >
    > > in short, if someone declares you as their MX (without your
    > > authorization), you should not start listing clients that try to send
    > > mail to such domains.


    On 24.07.08 14:35, Michelle Konzack wrote:
    > Are there ANY leagal reasons to declare someons MX as there MX?


    Yes, a mistake, or a false assumption by ISP's client.

    --
    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.
    Remember half the people you know are below average.


  8. Re: [OT] Odd spammer tactic?

    Michelle Konzack wrote:

    >> in short, if someone declares you as their MX (without your
    >> authorization), you should not start listing clients that try to send
    >> mail to such domains.


    > Are there ANY leagal reasons to declare someons MX as there MX?


    You miss mouss' point.

    If someone (maliciously or by mistake) declare your system as
    their MX, innocent third party mail servers may through no fault
    of their own connect to your system in order to send mail to
    addresses for wich your system is not a MX.

    If you allow the connecting system to get as far as RCPT TO: you
    could check if someone has set the MX for the recipient
    address(es) to point at your system before listing the client
    (and that would also give the opportunity to contact whoever is
    responsible for the bad MX record).

    For a well known connection trap, this might well be a very
    important precaution as spammers might otherwise try to poison
    the list.

    Regards
    /Jonas
    --
    Jonas Eckerman, FSDB & Fruktträdet
    http://whatever.frukt.org/
    http://www.fsdb.org/
    http://www.frukt.org/


  9. Re: [OT] Odd spammer tactic?

    Jonas Eckerman wrote:
    > Michelle Konzack wrote:
    >
    >>> in short, if someone declares you as their MX (without your
    >>> authorization), you should not start listing clients that try to send
    >>> mail to such domains.

    >
    >> Are there ANY leagal reasons to declare someons MX as there MX?

    >
    > You miss mouss' point.
    >
    > If someone (maliciously or by mistake) declare your system as their MX,
    > innocent third party mail servers may through no fault of their own
    > connect to your system in order to send mail to addresses for wich your
    > system is not a MX.
    >
    > If you allow the connecting system to get as far as RCPT TO: you could
    > check if someone has set the MX for the recipient address(es) to point
    > at your system before listing the client (and that would also give the
    > opportunity to contact whoever is responsible for the bad MX record).
    >
    > For a well known connection trap, this might well be a very important
    > precaution as spammers might otherwise try to poison the list.
    >


    exactly.

    More generally all the approches that are based on "this pattern means
    this is an attacker" must be seriously analyzed. this includes
    - "nobody should try to connect to this port". if you don't allow for a
    tcp session to be established, an attacker can spoof an IP and you would
    list an innocent IP.
    - "spammers close the connection without a quit". probably, but a
    connection may be broken for other reasons (system reboot, lost
    connectivity, ...).
    - "only spammers go to my second MX when my first is up". sure, but just
    because you see it p doesn't mean other people can connect to.
    - "this address only gets spam" (spamtrap). probably. but can you prove it?
    - ... etc

    what I mean is that you need to analyze your "rule" before implementing
    it. and you need to analyze your implementation as well.

    people often take care against many sorts of attacks. but when blocking,
    they don't realize that they are vulnerable to similar attacks. remember
    that fail2ban "injection" attack (you put the victim IP in the login, so
    that fail2ban blocks the victim IP)? and how many people try to block
    IPs because of port scans just to block victims of IP spoofing? ... etc.


  10. Re: [OT] Odd spammer tactic?


    On Fri, 2008-07-25 at 18:15 +0200, Jonas Eckerman wrote:
    > Michelle Konzack wrote:
    >
    > >> in short, if someone declares you as their MX (without your
    > >> authorization), you should not start listing clients that try to send
    > >> mail to such domains.

    >
    > > Are there ANY leagal reasons to declare someons MX as there MX?

    >
    > You miss mouss' point.
    >
    > If someone (maliciously or by mistake) declare your system as
    > their MX, innocent third party mail servers may through no fault
    > of their own connect to your system in order to send mail to
    > addresses for wich your system is not a MX.


    I think I still miss the point. How can someone else declare the MX of
    my domain. ( dns poisoning ignored ). If that were possible , he would
    be getting my mails which is much more a serious issue


    Anyway for the stats I just created two brand new "A" records with
    mail.domain.com just for testing , and pointed to a fake smtp server
    No Mxes pointing to that IP so no real mail should come here
    For the last 3 days , 154 distinct ips have connected and of them 144
    are already listed in zen.spamhaus.org

    So it doesnt seem to be a very useful effort afterall to list those
    ips :-(. I would have blocked those mails with spamhaus anyway


    Thanks
    Ram


  11. Re: [OT] Odd spammer tactic?

    ram wrote:
    > On Fri, 2008-07-25 at 18:15 +0200, Jonas Eckerman wrote:
    >[snip]
    >
    > I think I still miss the point. How can someone else declare the MX of
    > my domain. ( dns poisoning ignored ). If that were possible , he would
    > be getting my mails which is much more a serious issue
    >


    - I buy a domain, say foobar.example.
    - I declare the MX to point to your IP (your mailserver or anything else)
    - I write a message from mouss@foobar.example to sales/infos/jobs/....
    at some company, or I send a subscription request to a mailing-list
    - said company or mailing-list will then connect your your server trying
    to delivered to mouss@foobar.example
    - you consider this as a relay attempt and blocklist the _innocent_
    client IP.

    is it clear now?

    in short, if you see mail coming in that shouldn't come in, don't list
    the source without investigation.


    >
    > Anyway for the stats I just created two brand new "A" records with
    > mail.domain.com just for testing , and pointed to a fake smtp server
    > No Mxes pointing to that IP so no real mail should come here
    > For the last 3 days , 154 distinct ips have connected and of them 144
    > are already listed in zen.spamhaus.org
    >
    > So it doesnt seem to be a very useful effort afterall to list those
    > ips :-(. I would have blocked those mails with spamhaus anyway


    for people who want to reduce external calls (for both their good and
    that of spamhaus and friends), a local blacklist is advantageous.
    however, it doesn't come for free. you need to be careful when listing
    an IP, and you need to maintain the list (machines get fixed, IPs get
    reassigned, ... etc). if this is too much work, then forget about it.


+ Reply to Thread
Page 2 of 2 FirstFirst 1 2