Page 3 of 7 FirstFirst 12345 ... LastLast
Results 21 to 30 of 62

Thread: local mail getting marked as spam?

  1. #21
    mdeneen is offline Active Member
    Join Date
    Jul 2007
    Posts
    45
    Rep Power
    8

    Default

    Quote Originally Posted by dwmtractor View Post
    Perhaps, and that is why I said it would be perfectly reasonable to file an RFE (if you don't want to do so yourself, I'll be happy to try to translate it appropriately to a bugzilla request), however, I would definitely want it to be a switchable option. Here's why:

    Let's say you're sending messages to customers but they don't get through, because your IP (or IP range due to a sloppy ISP) has landed in somebody's public blocklist. How are you going to know that something is wrong? Your customers may not know you sent something that didn't come thru, unless you call them to verify, which sort of makes email redundant. On the other hand, if you find that email from yourself to yourself is getting caught in your own spam filters, it gives you a "heads up" that you need to research and determine why you're sitting on somebody's blacklist. You can take the necessary steps to remedy the situation, and your own system will monitor whether you've succeeded or failed.

    Failing that, you're left to wait for some customer to be upset because you never sent him/her that promised email, in order to discover that you have an issue at all. To my way of thinking that's not the ideal way to do the job. . .
    You misunderstood me. I have users using Thunderbird remotely. Let's say bob@example.com sends email to sue@example.com. Bob is on a different network and authenticates over SSL to send his email. Both are in the same domain, yet the message is checked for spam. I don't care what this email is, but I want it to get through. Mail sent through the Zimbra web UI to another local account is not checked for spam -- why should this be?

    To sum this up, I am ok with email leaving the domain being checked for spam. However, I think that mail between users in the same domain should never be checked if the user has authenticated themselves.

  2. #22
    dwmtractor's Avatar
    dwmtractor is offline Moderator
    Join Date
    Jul 2007
    Location
    San Jose, CA
    Posts
    1,027
    Rep Power
    10

    Default

    I understand you fully. The way to get this on the list is to file an RFE (Request For Enhancment) bug in the Bugzilla system. Once you've filed it, post back to this thread with the bug number that the system assigns, and encourage others to vote for the bug. If it gets enough votes, or if the guys who read the bugs agree (votes or no), it'll go into the hopper for future releases.
    Cheers,

    Dan

  3. #23
    bjquinn is offline Advanced Member
    Join Date
    Nov 2005
    Posts
    175
    Rep Power
    9

    Default

    Quote Originally Posted by dwmtractor View Post
    I'm betting that either his real domain (whatever myserver.com obfuscates) or else the internal 192.168.1.x range have landed in the blacklisters, so that other people "out there" who use the same blacklists would also have his email flagged. That's the first thing I would check based on the scores I am seeing.
    Here's a snippet from my headers I posted in the original post.

    Received: from MYHOSTNAME (ppp-70-251-124-xxx.dsl.rcsntx.swbell.net [70.251.124.xxx])
    by mail2.myserver.com (Postfix) with ESMTP id 3A5BD93400C7

    I'm only seeing this problem when my users are logging into the email server from outside the local network. Possibly (probably) their (potentially dynamic) IP is on a blacklist, but if they've successfully authenticated to my mailserver, they're not really sending mail from that IP, they're sending it from the local IP. The sender's IP ought to be 127.0.0.1 or the local or public IP of my mailserver, not the IP of the internet connection they're getting to my mailserver from! Also, I've checked and my mailserver does not appear to be on any blacklists (also I can send mail between this server and another Zimbra server on a different domains and IP range and they don't flag each other as spam).

    I'm not seeing this with users connecting from LAN addresses (192.168.x.x), but wouldn't that be something if the reserved local network address ranges ended up on blacklists? That would be strange! Who could have possibly submitted THAT to a blacklist???

    -BJ

    EDIT: I don't think I'm asking for exactly what dwmtractor thinks should be an on/off feature -- I don't necessarily want to suspend spam checking for authenticated users (who are themselves subject to viruses, of course) -- I only want to consider the "sending IP" that gets checked against the blacklists as the mail server the email sender authenticated into, whether it be my local mail server's IP for local users, or the remote mail server's IP for people not on my domain, or for virus spambots, the "mail server" is the virus itself since it never successfully authenticates anywhere else, and in that case, the public IP of the computer that has the virus. I think that should be a bugfix that would apply to everyone, not an on/off feature.
    Last edited by bjquinn; 07-25-2008 at 10:33 AM.

  4. #24
    dwmtractor's Avatar
    dwmtractor is offline Moderator
    Join Date
    Jul 2007
    Location
    San Jose, CA
    Posts
    1,027
    Rep Power
    10

    Default

    OK, NOW I see where you're coming from. Your statement
    but if they've successfully authenticated to my mailserver, they're not really sending mail from that IP, they're sending it from the local IP.
    is, of course, only true if their email client is set up properly. It is possible to have your client set up right for authentication (and receiving) incoming POP or IMAP messages, and still have the SMTP side set up to use the ISP's own SMTP server, which could lead to your issues. You need to be sure that the client is actually using your SMTP server, as opposed to relaying through the ISP's server TO your SMTP which is a horse of a different color.

    You can determine this by looking at mail.log or zimbra.log (both are found in /var/log) at the time a known message is sent, as well as from the full headers of the message. Your headers already tell us where to look, at least in part:
    Received: from MYHOSTNAME (ppp-70-251-124-xxx.dsl.rcsntx.swbell.net [70.251.124.xxx])
    by mail2.myserver.com (Postfix) with ESMTP id 3A5BD93400C7
    So the issue is, is your user's SMTP setup from their mail client going to swbell.net first, or does it THINK it's going straight to mail2.myserver.com?

    Questions:
    1. How have you set up your system to allow SMTP for the outside users? Did you add them to your allowed relays, or are they being authenticated by Zimbra?
    2. Are you (if not I recommend you do) using SSL/TLS for authentication and disabling cleartext authentication? This is not absolutely necessary for authenticated relay to work, but the advantage is you get more obvious errors if something is set up wrong, plus it's more secure anyhow. Part of the benefit is that then port 25 is only for ordinary relay, and 465 handles all the authenticated stuff
    Cheers,

    Dan

  5. #25
    bjquinn is offline Advanced Member
    Join Date
    Nov 2005
    Posts
    175
    Rep Power
    9

    Default

    Quote Originally Posted by dwmtractor View Post
    It is possible to have your client set up right for authentication (and receiving) incoming POP or IMAP messages, and still have the SMTP side set up to use the ISP's own SMTP server, which could lead to your issues. You need to be sure that the client is actually using your SMTP server, as opposed to relaying through the ISP's server TO your SMTP which is a horse of a different color.
    Of course, and depending on the user's ISP and connection type, port 25 may be blocked. I've added an alternate SMTP port (8025) to handle that situation. I understand using the SSL port may have been better, but this just happens to be the port we've been using for this purpose for several years now. I added the extra smtp port by modifying /opt/zimbra/postfix/conf/master.cf.

    Quote Originally Posted by dwmtractor View Post
    You can determine this by looking at mail.log or zimbra.log (both are found in /var/log) at the time a known message is sent, as well as from the full headers of the message. Your headers already tell us where to look, at least in part:

    So the issue is, is your user's SMTP setup from their mail client going to swbell.net first, or does it THINK it's going straight to mail2.myserver.com?
    We set them up to use port SMTP port 8025 and to use our mail server as the outgoing mail server / SMTP server.

    Quote Originally Posted by dwmtractor View Post
    Questions:[*]How have you set up your system to allow SMTP for the outside users? Did you add them to your allowed relays, or are they being authenticated by Zimbra?
    They're being authenticated as described above (w/o SSL), but not using the ISP's SMTP server.

    Quote Originally Posted by dwmtractor View Post
    [*]Are you (if not I recommend you do) using SSL/TLS for authentication and disabling cleartext authentication? This is not absolutely necessary for authenticated relay to work, but the advantage is you get more obvious errors if something is set up wrong, plus it's more secure anyhow. Part of the benefit is that then port 25 is only for ordinary relay, and 465 handles all the authenticated stuff[/LIST]
    I'm not, but I understand the reasoning for it. I would consider moving to that if it would help.

  6. #26
    bjquinn is offline Advanced Member
    Join Date
    Nov 2005
    Posts
    175
    Rep Power
    9

    Default

    In other words, am I correct in assuming that Zimbra shouldn't be exhibiting this behavior for authenticated SMTP users for local mail?

  7. #27
    bjquinn is offline Advanced Member
    Join Date
    Nov 2005
    Posts
    175
    Rep Power
    9

    Default

    Ok, so does anyone know if using port 465 helps or if there's any other workaround?

    Also, for what it's worth, I think this problem can be solved for the people who don't roam from place to place with their laptops - just have them use their ISP's SMTP server, which hopefully won't be detected as a blacklisted IP by Zimbra. However, there doesn't currently seem to be a solution for mobile users.
    Last edited by bjquinn; 08-01-2008 at 07:59 AM.

  8. #28
    dwmtractor's Avatar
    dwmtractor is offline Moderator
    Join Date
    Jul 2007
    Location
    San Jose, CA
    Posts
    1,027
    Rep Power
    10

    Default

    Quote Originally Posted by bjquinn View Post
    Also, for what it's worth, I think this problem can be solved for the people who don't roam from place to place with their laptops - just have them use their ISP's SMTP server, which hopefully won't be detected as a blacklisted IP by Zimbra. However, there doesn't currently seem to be a solution for mobile users.
    Actually that's NOT a good idea, as many spam filters (including SBC/Yahoo/AT&T and Gmail) will classify as spam any message where the return path is a different domain than the sending SMTP server.

    I still would look more into the side of what, exactly, is getting blacklisted. I believe you said you checked your server's IPs and they weren't listed in the SORBS blacklist (if you haven't checked, you should). If this statement is true, then the fact that you're getting nailed by SORBS means something else in your path IS listed, and you need to find out what. Same with Pyzor. . .I can't speak to Pyzor's performance because I haven't used it myself, but again you don't want your SMTP server to be listed with Pyzor and if it is, you're gonna have problems sending mail to others as well as yourself.

    But since, as we discussed earlier, you are not seeing similar blacklisting for your own IPs, I'm guessing it's not your mailserver that's blacklisted, though I would go to their websites and double-check the verification.

    It is possible (and here I have to defer to the people who know SpamAssassin better than I do) that there is a bug in the SpamAssassin logic that is validating all IPs along the path rather than (as you suggested) bypassing those IPs in the check for authenticated users. I agree with you that if this is the case it needs to be fixed, and we need to submit a bug to that effect. But the only way I can think of to validate that bug would be to plug in the various IPs of all the header "received from" lines in a mail header and see which ones Pyzor or SORBS rejects. Then you could verify which specific bit the system is tripping over, and that's the information that will be necessary to file the bug.

    Finally, if you're satisfied with spam performance for the rest of your system, you could just lower the point scores for (or turn off) Pyzor and SORBS on your filtering, and the rest of the spamassassin filters would continue to do their jobs. It's a kluge, and it wouldn't help in fixing the underlying problem, but it would work around your issue.
    Cheers,

    Dan

  9. #29
    bjquinn is offline Advanced Member
    Join Date
    Nov 2005
    Posts
    175
    Rep Power
    9

    Default

    Quote Originally Posted by dwmtractor View Post
    But the only way I can think of to validate that bug would be to plug in the various IPs of all the header "received from" lines in a mail header and see which ones Pyzor or SORBS rejects. Then you could verify which specific bit the system is tripping over, and that's the information that will be necessary to file the bug.
    Actually, I posted a full set of headers at the beginning of this topic, and as you can see, there's not a whole lot of "received from" lines. Since the user is actually a "local" user accessing the mail server remotely, sending an email to another local user, there are only two public IPs that could be checked - my mailserver's IP (which, as I've just checked again, is not on any blacklists - and checking against this would be stupid anyway, since it's the local mail server!) and the IP address of the internet connection they're sending out mail from, which is NOT a mail server, and therefore shouldn't be checked against blacklists. There's not actually a bunch of mail servers in the path here - just one, mine. One could debate about whether Zimbra should trust itself or not (and verify its own IP against blacklists), but my Zimbra server is not on any blacklists and there aren't any other mail servers involved, period.

  10. #30
    dwmtractor's Avatar
    dwmtractor is offline Moderator
    Join Date
    Jul 2007
    Location
    San Jose, CA
    Posts
    1,027
    Rep Power
    10

    Default

    Quote Originally Posted by bjquinn View Post
    and checking against this would be stupid anyway, since it's the local mail server!)
    True, particularly since nearly every mail server out there has localhost somewhere in their path;
    Quote Originally Posted by bjquinn View Post
    and the IP address of the internet connection they're sending out mail from, which is NOT a mail server, and therefore shouldn't be checked against blacklists.
    Not true. In fact an awful lot of spam "out there" comes, not from a normal mail server, but from the SMTP engine of a virus or worm on somebody's DSL connection. This is why many blacklisting servers DO, in fact, check those IPs. This line:
    Received: from MYHOSTNAME (ppp-70-251-124-xxx.dsl.rcsntx.swbell.net [70.251.124.xxx])
    has been obfuscated in your post so I can't check it myself, but I'm betting, since it's Southwestern Bell's DSL dynamic address space, could very well be on the SORBS blacklist. This would happen if one or more 'bot computers in Southwestern Bell's space have been spamming, and your roadwarrior user could very easily be painted with the same brush. It's one of several reasons a lot of people go away from using dynamic DSL connections for their mailserver, as they get shut down by blacklists pretty frequently. You can see from SORBS' own web page that they do, in fact, block quite a number of dynamic IP spaces.

    Thus, while I can't verify it without the full IP address, I'm pretty sure this is what is happening to you.

    Now as I said before, there is a valid argument in your contention that regardless of IP source, if your user is properly authenticated Zimbra should allow the mail thru. I understand the argument and I'm really not trying to argue against you. But it's obviously not what's happening now, and in order to fix what's happening, we need first to understand why, precisely, the mail is getting blocked. I have my theory, which you can test and support or deny if you wish. Once we have that precise mechanism defined, which would require that you validate the IP that is being blocked or prove me wrong, then we have something that can be filed in an RFE or bug report. Until then, you're asking for a shotgun fix that I doubt you'll get.

    And my previous point remains true--if you are getting blocked internally, you can bet that the same user's emails, under similar circumstances, will be blocked externally by others who use SORBS. So IMHO Zimbra is doing you a favor in helping you to identify and fix the problem before an upset customer doesn't get the communication he's expecting.

    Perhaps what you're really asking is that Zimbra would, in cases of authenticated SMTP, strip out all prior headers and send out the message as though originating from the Zimbra IP itself. I don't know if that's consistent with the SMTP standards, so I can't even tell you if it's permissible or not--others will have to do that. But it would solve the problem.
    Cheers,

    Dan

Page 3 of 7 FirstFirst 12345 ... LastLast

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Similar Threads

  1. Replies: 7
    Last Post: 02-03-2011, 07:01 AM
  2. Problem with Postfix and MTA
    By ZMilton in forum Administrators
    Replies: 16
    Last Post: 04-16-2008, 06:47 AM
  3. [SOLVED] Mailserver down when send file attach of 50Mb
    By ZMilton in forum Administrators
    Replies: 20
    Last Post: 04-10-2008, 11:44 AM
  4. fresh install down may be due to tomcat
    By gon in forum Installation
    Replies: 10
    Last Post: 07-25-2007, 08:09 AM
  5. receiveing mail
    By maybethistime in forum Administrators
    Replies: 15
    Last Post: 12-09-2005, 04:55 PM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •