sendmail help: how do I tell evite to fuck off?

Evite (owned by TicketBastard) are address-harvesting web-bug-using spamming cocksuckers, and I'd like to never receive mail from their service. Preferably, in such a way that whichever acquaintance of mine who is foolishly using their service gets a bounce, so that they know I didn't get evite's email.

Evite's mail headers are clever: they set the envelope-from to the human dupe on whose behalf they are sending the mail, but the mails themselves originate at

    Return-Path: <address-of-human@wherever>
    Received: from ( [])
    by [ local server...] (envelope-from address-of-human@wherever)
    Received: (qmail 15737 invoked from network); 16 Aug 2003 01:57:14 -0000
    Received: from (HELO (
    by 0 with SMTP; 16 Aug 2003 01:57:14 -0000
    From: <>
    Reply-To: <address-of-human@wherever>

I tried adding this to /etc/mail/access:   550 Spamming denied 550 Spamming denied
but it didn't work. Any suggestions?

(Note: Suggestions that involve procmail, or that involve installing any mailer other than sendmail 8, will be gleefully ignored, so please don't waste your time.)

>Update, 7-Sep-2003:

The prevailing theory had been that I could do this, since Evite was always including X-Sender:

    HX-Sender: $>Check_XSender
    D{MMsg}Spamming denied
    R${MPat} $*$#error $: 553 ${MMsg}
    RX-Sender: ${MPat} $*$#error $: 553 ${MMsg}

But now those cockgobblers have changed their X-Sender header to be the human sending the evite, making it useless for filtering. My next try is to filter on the Recieved headers and try and bounce anything that comes from citysearch:

    HReceived: $>Check_Received
    D{MMsg}Spamming denied
    R${MPat} $*$#error $: 553 ${MMsg}
    RReceived: ${MPat} $*$#error $: 553 ${MMsg}

(There's a TAB after $*.)

(I can't just block based on IP addresses because my mail server is behind my ISP's relay host, so the hostile mailers never connect to me directly.)

Tags: , , ,

41 Responses:

  1. wasteddream says:

    Oops. Sorry, dude. I'm all not smart about this kind of thing. If you come to my party anyway, you can sit on the wireless network with hep and make fun of everyone else there. DOESN'T THAT SOUND LIKE FUN??

    • jwz says:

      Hey, it's not just you, I've gotten two evites this week! (which means "two more people who entered my email address in the 'spam me senseless' sweepstakes, enter as often as you like, you may already have won.")

  2. grahams says:

    I know this sounds terribly naive, but according to their privacy policy you can opt-out of all that....

    • jwz says:

      If you can show me a place on their site where it is possible to opt out, I'd be appreciative, because I certainly couldn't find it.

      In each of the evites is a link that says "don't send me mail from this person again", and sure enough, that only works for that one person (or possibly only that one event.) There's no way that I've seen to tell evite-as-a-whole to FOAD.

      • grahams says:

        Log in with the email address the "inviteee" used, click on "My Profile" in the green navbar across the top of the page, and un-check the "Yes, I'd like to receive Evite news and special offers" checkbox.

        Of course, all of this assumes they abide by their privacy policy.. Call me tinfoil hat, but I doubt they do that....

        • jwz says:

          I can't believe they'd consider "invititation from ____" to fall under the umbrella of "evite news and special offers". That checkbox has to mean "think about maybe not directly spamming me above and beyond the invitations."

          Being a TicketBastard subsidiary, I assume (without having read through their whole privacy policy) that they also make no promises about what their "partners" will do with your info that they've already shared.

          • mcfnord says:

            This evite thing sounds complicated because your friends give your email to the site.

            You are saying it is not straightforward to suppress spam through evite?

            i hate that.

          • kfringe says:

            Effectively, their "partners" will put any address they see on the permenant "fuck me harder" list.

          • insomnia says:

            Hi Jamie. I found out about your Evite post after a bit of googling.

            I recently looked into the issue of Evite and spam, as one of my friends mentioned that they were spamming people. Fortunately, it appears that they are no longer doing so, probably in response to the feedback they were getting from consumers and news articles. I also asked for clarifications on their privacy policies, and they appear to be fairly appropriate. (i.e. You must now opt in for spam before it is sent, instead of opting out after the fact.)

            Thought you might like to know.

            • jwz says:

              Regardless -- I don't ever, ever want to receive mail from the evite system. They give me no way whatsoever to opt out.

              Evite can suck it.

    • kchrist says:

      Are you sure about that?

      While Evite does not give users the opportunity to remove their information from our database, you may remove your registration information from our Profiles page as described below.

      (emphasis mine)

      That's straight out of their so-called privacy policy. Read it and weep. Please note that they also say they may send mail to recipients of invitations as well as the people actually using the service for their own events. Basically, it's a big database of confirmed-good e-mail addresses.

      I didn't realize they were owned by Ticketbastard. That gives me even less faith in their intentions (if that's actually possible).

      • jonabbey says:

        3. Use of Guest Contact Information:

        We use your guests' contact information to allow them to respond to and comment on your Evite invitation. At your request, we may send reminders to your guests and display their e-mail addresses to your other guests. We also may send a post-event e-mail to you and your guests. If you use our Reminders service, we use the information you provide in your Reminders to send it to you and others to whom you have requested it be sent. Evite does not sell, share or otherwise provide any guests' contact information you give to us with any third party without your consent, unless required by law, court order or as required to technically operate the service.

        So they've at least making the right monkey noises about that part of it, anyway. They do go on to note that if they get acquired, you may be screwed, sorry.

  3. Is there an interesting or entertaining story behind your dislike of procmail? Or is it just an irrational, knee-jerk kind of thing?


    • jwz says:

      What, you mean aside from its syntax being an offense to God and Man?

      I don't need it, I don't use it, and I don't intend to start.

  4. edm says:

    The lines that you list should match the injecting host (ie, providing you've enabled the access database (using FEATURE(access_db)), and rebuilt the access database hash map (using something like: makemap hash /etc/mail/access < /etc/mail/access). You may also need tabs not spaces to separate the LHS and RHS (sendmail is rather fond of tabs). They will also try to match the envelope address, but won't (AFAIK) match the body addresses and hence the second one you list won't be of much use.

    This google cached link: Allowing controlled SMTP relaying in Sendmail 8.9 and later (google cache) may help. I'd give you a direct link but is down. (I also remember finding a better description of advanced access_db features (eg, identify type of entry the access_db entry related to) in the past, but with down (connection refused) I can't seem to find it. It's also not in my O'Reilly Sendmail book so it must have been online.)


    • jwz says:

      Yes, I rebuilt the DB. I have other entries in there that do work, so I know it's being consulted and that the syntax is right.

  5. jwz says:
    <cyantist> i like how you have to add a disclaimer so that people don't try to persuade you to use something else rather than actually answering your question
    <jwz> imagine how many procmail/qmail recipes I would have gotten without that preemptively snotty parenthetical
    <cyantist> tons!

    metric fucktons

    cubic assloads
  6. b_a_t says:

    AFAIK, sendmail in access.db works with envelope MAIL FROM: and RCPT TO:. These addresses maybe different from what you have in mail headers... So try to ban addresses mentioned in the Received: headers as
    envelope-from address-of-human@wherever. Particulaly, 'whatever' domain. Hope, that will help...

  7. endquote says:

    "Address-harvesting web-bug-using spamming cocksuckers?" I don't know.. I don't think I've gotten any evite/ticketmassah spam, or at least not anything Spamassassin didn't catch anyway. What got them on your bad side?

    (Unrelated: Been following the DNA blog since long before opening, hoping to check it out while I'm in SF next weekend.)

    • jwz says:
      1. I have gotten spam from Evite in the past.

      2. As for TicketBastard, read the link I posted above for their latest of many affronts. Since Evite is a TicketBastard subsidiary, I think it's assured that when someone sends you an Evite, then Evite will turn around and share your address (the invitee, not the inviter) with their "partners" with no opt-out (let alone opt-in), just like TicketBastard does.

      3. Look at the source of any Evite HTML mail: there's a 1x1 image in it whose sole purpose is (trying to) track whether you've opened the mail! That's just Plain Fucking Evil.

      4. And plus, I hate their service on the general principle that when someone is inviting me to something, the mail should contain the info -- for example the date -- instead of making me have to click a link, have ads thrown at me, and submit to tracking by some corporation. Not to mention the spam.
      • aitp says:

        WRT #3, I agree it's evil, but tell me you don't allow external image loading in your email client! Otherwise, my whole image of "Jamie, Code Warrior par Excellence" dies tonight.

        Okay, so, I'm a bit big on the whole melodrama thing. Can you tell?

        Insofar as your actual problem, try doing what I do--at your border router, route their netblock onto lo (or firewall it if you want to be fancy--I like routes 'cause they're pretty). SMTP is TCP, so if you can't SYN/ACK back to them, they can't spam you.


        • jwz says:

          Puh-lease as-if. But still!

          I can't just de-route them because my MX points at one of my ISP's machines, not my own, so I never actually see packets from Evite directly; there's a forwarding hop in the way. (This is on purpose: I like having it set up so that only my ISP can SMTP to me, not the whole wide world, because that way it's not as critical that I track the sendmail-exploit-du-jour on my personal machine: there's another network in the way before the kiddies can get to me, since my SMTP port is firewalled off.)

          So I think this means that all I have to go on here is the contents of the envelope and the payload headers. And it would appear that /etc/mail/access only keys off of 821 FROM, not off of 822 Sender. But I'm using <lj user="anonymous_bozo">'s suggested heiroglyphs now, so we'll see if that works...

          • aitp says:

            /me endorses <lj user=anonymous_bozo>'s suggestion. (And mumbles "qmail" to himself under his breath.)

            In all seriousness, I strongly suggest you reevaluate your choice of MTA. You said it yourself—the sendmail-exploit-du-jour largely invalidates the potential arguments against other systems; why are you holding out?

            I mean, hell, one of the root nameservers is now running on something other than BIND. I see sendmail and BIND as beautiful things handed to us by an older generation of hackers, which the new hackers blasphemed because they knew not what they were doing. Like EMACS--once a beautiful editor, now an operating system that's one good text editor short of usability.



            • jwz says:

              Because it's installed by default and I (mostly) don't have to think about it. And when I do, I already (mostly) know how to use it. And my firewall situation means I don't have to care too much about its pathological hackability.

              Also djb is a jackass and I have an anti-jackassware policy (were I a qmail user, I might someday have to exchange mail with him again, and I've reached a point in my life where I'm just no longer willing to subject myself to that sort of thing.)

              • aitp says:

                Okay, yep, djb sucks.

                Wasn't there a super-easy-to-use Linuxconf module for sendmail at some point?


                • waider says:

                  Wasn't there a super-easy-to-use Linuxconf module for sendmail at some point?

                  Yes, there was, but:

                  1. It was based off fragments which it reassembled according to how you wanted sendmail configured. Meaning if you upgraded sendmail you were still going to end up using old config stuff
                  2. It didn't achieve much more than is being discussed here; in some cases, it achieved less.
                  3. Linuxconf appears to be damn near dead at this point.

                  I spent some time working on a m4 config module for Linuxconf, which mostly worked, but really, it's far easier in the long run to learn the m4 config stuff manually and just drop in the bits you need. Of course, sometimes you still have to resort to using the heiroglyphs and subsequently mumbling "defocus" in your sleep.

              • moof says:

                If, in the unlikely event you want to recompile your kernel change MTAs, you may want to look at postfix; Weitse Venema's pretty good at being anal-retentive in regards to security, and the configuration syntax is zillions of times easier than sendmail (or qmail) - it at least uses Demotic instead of those sideways fish.

          • edm says:

            I can't just de-route them because my MX points at one of my ISP's machines, not my own, so I never actually see packets from Evite directly; there's a forwarding hop in the way.

            Ah. That explains why the access database entry doesn't work -- it is working off the host that is sending the mail to your mailserver, and that's your ISP not at the time the mail is being received and checked against the access database. Since evite so kindly forges the envelope that means there's nothing left that the access database can filter on. (I assume they forge the envelope to avoid getting the bounces, and to work around broken MUAs which reply to the envelope address instead of Reply-To: etc as God intended.)

            Now that is back up again, I found the more detailed page on the access database I was thinking of: Anti-Spam Configuration Control. That also confirms that the access database applies only to the envelope (RFC2821) details, rather than the body (RFC2822) details.

            Given the hidden source mail server (hidden by all mail going through your ISP) and the forged envelope from address (kindly forged by, you're left with doing content-based filtering (ie, of the RFC2822 message) some other way. More recent versions of sendmail can do some of this internally, as shown both on the Anti-Spam Configuration Control page (near the end), and also in <lj user="anonymous_bozo">'s suggestion. Both could be generalised to work off a database of gratituously stupid sites if required. Or you can use milters, procmail, perl, whatever to do it.


  8. node says:

    From: <>

    If that's in every message, try this in your .m4 or .mc file:


    HX-Sender: $>Check_XSender


    D{MMsg}Spamming denied


    R${MPat} $* $#error $: 553 ${MMsg}

    RX-Sender: ${MPat} $* $#error $: 553 ${MMsg}

    There are tabs betwen $* and $#.

    • jwz says:

      That looks promising... I'll give that a try, thanks!

      (Mmmm, tasty line noise.)

      • zztzed says:

        <shodan> I'm kinda surprised that after all this time, sendmail's config is still based on ancient hieroglyphs
        <shodan> . o O ( To enable sender-validation in sendmail, enable this option: bird, squiggley line, sideways man, fish )

  9. ok, i know jack about sendmail and i use procmail because it's easy for me, but i find it hard to believe that it'd be that difficult to set up sendmail or whathaveyou to just do something really obvious like "take all mail from * and send it to perl script x that does what i want it to do". is this not the case?

  10. tippus says:

    The solution is really simple. Your friends are obviously incompetent if they are giving your EMail address to spammers. I'd block your lame friends. This would counter spoofing from spammers claiming to be your friends.