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 citysearch.com:
Return-Path: <address-of-human@wherever>
...
Received: from lax1evtmx7.citysearch.com (lax1evtmx7.citysearch.com [209.104.61.33])
by [...my local server...] (envelope-from address-of-human@wherever)
Received: (qmail 15737 invoked from network); 16 Aug 2003 01:57:14 -0000
Received: from lax1evtwww14.prod.tmcs (HELO lax1evtmx5.citysearch.com) (192.168.61.114)
by 0 with SMTP; 16 Aug 2003 01:57:14 -0000
X-Sender: info@evite.com
From: <info@evite.com>
Reply-To: <address-of-human@wherever>
I tried adding this to /etc/mail/access:
citysearch.com 550 Spamming deniedbut it didn't work. Any suggestions?
evite.com 550 Spamming denied
(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
- LOCAL_RULESETS
HX-Sender: $>Check_XSender
D{MPat}info@evite.com
D{MMsg}Spamming denied
SCheck_XSender
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:
- LOCAL_RULESETS
HReceived: $>Check_Received
D{MPat}citysearch.com
D{MMsg}Spamming denied
SCheck_Received
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.)
http://www.cm.nu/~shane/lists/comp.mail.sendmail/2003-06/0335.html
Don't know if this is for sendmail 8 though.
-Ben
That's exactly what I did, above.
It might make a difference. Maybe.
-Ben
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??
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.")
I know this sounds terribly naive, but according to their privacy policy you can opt-out of all that....
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.
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....
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.
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.
Effectively, their "partners" will put any address they see on the permenant "fuck me harder" list.
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.
-m.
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.
Are you sure about that?
(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).
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.
Is there an interesting or entertaining story behind your dislike of procmail? Or is it just an irrational, knee-jerk kind of thing?
[j]
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.
The lines that you list should match the injecting host (ie, anything.citysearch.com) 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 http://www.sendmail.org 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 http://www.sendmail.org 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.)
Ewen
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.
Google's new calculator doesn't know what to make of metric fucktons or cubic assloads. Please provide conversion factors so that I may use these colorful units.
I think cyan has her units screwed up. The most well-known unit is "metric assload".
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...
"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.)
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.
AITP
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...
/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.
</RANT>
AITP
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.)
Okay, yep, djb sucks.
Wasn't there a super-easy-to-use Linuxconf module for sendmail at some point?
AITP
Yes, there was, but:
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.
If, in the unlikely event you want to
recompile your kernelchange 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.Ah. That explains why the citysearch.com 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 citysearch.com 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 sendmail.org 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 evite.com), 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.
Ewen
If that's in every message, try this in your .m4 or .mc file:
LOCAL_RULESETS
HX-Sender: $>Check_XSender
D{MPat}info@evite.com
D{MMsg}Spamming denied
SCheck_XSender
R${MPat} $* $#error $: 553 ${MMsg}
RX-Sender: ${MPat} $* $#error $: 553 ${MMsg}
There are tabs betwen $* and $#.
That looks promising... I'll give that a try, thanks!
(Mmmm, tasty line noise.)
<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 )
"Sendmail Configuration for Mummies"
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 *@evite.com and send it to perl script x that does what i want it to do". is this not the case?
It's really easy, anonymous_bozo explained how: you do it with "bird, squiggley line, sideways man, fish".
... of course that assumes you never pyramid your code.
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.