Jump to content

claco

Members
  • Content Count

    11
  • Joined

  • Last visited

Community Reputation

0 Neutral

About claco

  • Rank
    Member
  1. claco

    Keep getting blocked

    I'm not a Cisco or security guru, so I can't say. I can just give pointers as to why the telnet HELO output posted earlier might have been screwy. :-)
  2. claco

    Keep getting blocked

    Search Google for "postfix cisco fixup". http://archives.neohapsis.com/archives/pos...01-06/1198.html This issue usually effects older versions of IOS, and different email servers other than postfix.
  3. claco

    Keep getting blocked

    While completely unrelated, I've see mail servers behind certain versions of Cisco PIX firewalls munge the mail HELO like that. I think the culprit was the smtp fixup + the IOS version.
  4. claco

    SpamTrap+DoubleOptIn?

    It's no windfall, but it's a start: Baby steps. One battle at a time.
  5. claco

    SpamTrap+DoubleOptIn?

    Right. But there is no way that an order confirmation email can get to a spamtrap, unless the customer entered that address. This was my primary course of action Friday. I sent Ellen full copies of our outgoing order and shipping confirmation emails. I don't believe that people requesting catalogs get any sort of confirmation email at that time. Even if they do, they're certainly not the same as the order confirmation email caught in the spamtrap. For that matter, and tie ins with mailing lists of sales emails are a red herring for this thread. Those types of emails go out from a completely different server. Any problems they cause should lead to the blocking of that server ip address, not the one in the beginning of thie topic. -=Chris Unlikely or not, that is the only way an order confirmation email could end up in a spam trap. The customer would have had to enter that email. It's not like we just make up order confirmations and send them out to random addresses. It's an order confirmation from a non-web business system, not a newsletter, or an email generated from some web server page. I won't deny the bounces are the bulk of our problem here. My main point was the issue of that lack of information and the fact that the last email I was given from disputes was an order confirmation. We don't buy emails. And again, confirmed opt-in is not my call, no matter how much I bitch about it. It's easy to blow off an order confirmation, but those kinds of problems snowball when left alone. If it happened once, it will happen again in all likely hood. I know it's easy to say who cares, if the customer was mad, they'll contact us, but that's not how we conduct business. What? I've never mentioned or requested anywhere in this thread that I was trying to remove user submitted reports. The more of those we get, the better (to help convince people that confirmed opt-in is necessary), esp. reports about the server/ip that sends sales newsletters. This is a spamtrap issue, not a user report issue. And I did not stop dealing with Ellen. I simply went home at 5:30pm on a Friday and started talking about it here. :-)
  6. claco

    SpamTrap+DoubleOptIn?

    Someone tell this page then: SpamCop.net - SpamCop FAQ: Double/Confirmed Opt In: http://www.spamcop.net/fom-serve/cache/406.html ;-)
  7. claco

    SpamTrap+DoubleOptIn?

    I'd love to. I fought against it. It should always be off by default. Not my call or decision, and marketing rules the roost in this situation. But again, what does the catalog request page have to do with an order confirmation from a real order going to a spamtrap address? I guess I don't see the connection, since it's "near impoosible for someone to guess a spamtrap address". If the email in the spamtrap was some stupid sales newsletter email we sent out, I could understand it all. But an order confirmation is a different bird. I never claimed we do confirmed opt-ins. I've also fought for that for years. See previous paragraph. No clue since I don't run it. Running telnet now... let's find out. .... Looks like we accept emails for any address at our domain. I assume this is due to the Imail server having a nobody[at] address to catch all mistyped addressed so they can be routed the correct people. I'd also assume that the bounces happen when the email box that accepts these emails is full.
  8. claco

    SpamTrap+DoubleOptIn?

    Define "order a catalog"? They would have to place an order for real products using a real credit card. They certainly could seed a spamtrap address when placing an order. But, every says it's next to impossible. s/double opt-in/confirmed opt-in/. Send an email to the submitted address, and requiring a reply, or web link click to confirm they are the email address.
  9. claco

    SpamTrap+DoubleOptIn?

    Me neither. WIthout seeing the email, I'm flying blind. The order sysm isn't attached to the internet. I can/does send email order confirmations for orders also place over the phone, and order place over the internet, the worst that would happen is that it will accept any email address the cusotmer has entered on the web site. How could this be a problem with the order confirmation software? We took an order, maybe even over the phone, and the system sends out an email to the specified address in the order details. There's not much room in there for anything nefarious. I guess time will tell. Thanks, -=Chris Well, if it's near impossible that a customer found an entered a "secret hard to guess" spamtrap address into an order form, then it should be just as unlikely that a spammer would sent out a spam, with a "secret hard to guess" spamtrap address in the forged From/Reply-To for me to send a bounce to. RIght? That's why I said that my bounce problem would yield user submissions, not automatic spamtrap catches.
  10. claco

    SpamTrap+DoubleOptIn?

    Confirmed Opt-In, Double Opt-In. Who cares. Worrying about what spammers call it in this forum context amounts to a what-text-editor-is-best holy war. Even if the email server is bouncing back to forged From/Reply-To addresses, that would end up as user complaints/submissions, not spamtrap catches. Since I'm not the current maintainer of the email server in question (Imail. Ick.), I can't testify as to how if deals with bounces on forged froms....and that wan't the point of my post. My point was that fact that there is an email in the spamtrap, that appears to be a real order confirmation. An email which I'm not allowed to view, or inspect to find the offending order/customer number so that we can mark them as undeliverable so this won't happen again the next time the user places an order. That's all management cares about, and that's all I'm permitted to care about at the moment. With that said, how do I get more information about the other incidents above to see what the cause was? I don't think I misunderstood this: That's a order confirmation email, generated by the biz system and sent out the door, not generated from a web server or any form. But again, without the ability to actually view the thing, I can't confirm it's real. No other mention of the other incidents was made in the conversation about why we were blacklisted in the last 24 hours. Like I said, I'm ok with being blacklist due to issues with bounces. But the fact that a spamtrap has cought a real customers order confirmation has me more than concerned, if for no other reason than that customer isn't getting the information they need about their order/shipment; and the fact that I can't fix it for the customer. The bounce issue can be corrected. (P.S., thanks for the help. :-)
  11. I've been in contact with a very helpful and patient lady (Ellen) at 'disputes' about our recent listing. since I've asked a lot of questions and I'm sure she would like to get some other work done, I figure I would move over to the forums for more help. Our primary server (208.44.49.5) was listed with the usual spamtrap reason: After asking a few questions, I was able to find out that the subject of the email trapped was an order confirmation email we sent out in response to an order place in the system. I haven't yet been able to confirm that the body of the message is actually matches the test we use for order confirmation emails. Assuming it is a real order confirmation that was caught in a spamtrap, I have a few issues and questions about how to keep this from happening again. I'm sure the first question/suggestion will be to double-opt-in all email addresses we accept. Leaving all corporate politics/policies aside, I'm curious at a technical level how this can be achieved without ending up on the blacklist via another spamtrap. Let's assume that: The user places an order, submitting an email address We send a 'double' opt-in confirmation email to that email address The opt-in email goes to a spamtrap Now we're blacklist for doing the right thing Now I know what you're going to say: "spamtrap emails are secret". I would argue that given the present situation that we were blocked by a real order confirmation*, that is either not entirely true, that we have a customer who plucked a spamtrap address from a web page somewhere, or that by complete accident, they mis-spelled an address close to a spam trap address. * again, assuming the email caught matches what we send out. I can't say since I can't inspect the caught email. So, all things being equal, what can be done here? It seems that the spamtraps, (not just these, but spamtrap email addresses on websites) can be used to put innocent peoples email servers on the blacklists. Even if they are doing double-opt-in confirmation emails, that email itself would be a trigger. -=Chris
×