1. This forum is read-only and considered to be an Archive. Please utilize the SmarterTools Community for future interaction and posts.

SMTP Blocking vs Trusted Sender?

Discussion in 'SmarterMail' started by csimo, Sep 30, 2008.

  1. csimo

    csimo Product Expert

    I'm just starting to work with SMTP Blocking via RBL's, but have a question.

    Let's say I want to SMTP BLOCK any inbound message that fails zen.spamhaus.org. A user complains that they didn't receive a valid message and I tell them to put the sender address@domain.com in their Trusted Senders list.

    Am I correct in assuming that even if the inbound message failed zen.spamhaus.org it would be delivered if the recipient has added the senders address or domain in their Trusted Senders list?

    Thanks,

    -Joe
  2. csimo

    csimo Product Expert

    After reviewing the logs I think my assumptions are wrong.

    It appears in the case of an SMTP Block the only thing that is checked is the "from" address. The 554 rejected message is sent out by SmarterMail before the RCPT TO is received.

    In other words the message is rejected before SmarterMail knows who the message is sent to.

    So it appears that if you decide to do SMTP Blocking based on RBL's and you have a chronic false positive there's not much you can do about it.

    -Joe
  3. ST-JLance

    ST-JLance New Member

    You are correct. SMTP blocking occurs before the recipient information is known, and as such, a trusted senders list can not be used.
    You can allow them by IP address, though.
  4. csimo

    csimo Product Expert

    I sent the below in as a suggestion. The existing method doesn't make much sense (to ignore the Trusted Sender list).

    Currently SmarterMail grabs the IP Address after the HELO/EHLO command and then gets the MAIL FROM before implementing the SMTP Block.

    Even if the recipient has the sender (Mail From) in their Tusted Senders list the SMTP session is blocked (not good).

    I suggest that you wait until you get the RCPT TO info, then check that against the Trusted Sender list for the recipient. If the sender is not in Trusted Sender list for the recipient then block the session.

    Very little bandwidth involved and no data. This would resolve a big problem with using SMTP blocking.

    Hope you will take this into consideration and implement it. If not I'd really like to understand the logic of why not to wait for the RCPT TO info.

    Thanks,
    -Joe
  5. ramiss

    ramiss Senior Member

    Actually they way it works curently does make sense if you understand what SMTP blocking is used for. SMTP blocking was primarily developed because of the massive overhead that spam processing can have on a server.

    To process the message before the connection is blocked defeats the purpose.

    What you should do is have the RBL set a high spam weight and then set all spam with that weight to delete. Then the trusted sender list should override the deletion.
  6. ramiss

    ramiss Senior Member

    It should be pointed out, however, that blocking a server outright is the best thing in the long run and for the spam community. It forces the mail server's admin to take responsibility for, and remove themselves from the RBL.

    If you start allowing a blocked IP then they have no incentive to take care of why they were blocked, which hurts them when they send to other servers and weakens the role of RBLs.

    A very high percentage of IPs listed on RBLs are there because they allowed spam to be sent from their server. As a community we need to crack down on mail server admin's who take this lightly. However, I do recognize that false positives exist and no system is perfect.
  7. csimo

    csimo Product Expert

    I don't think you understand how this is working and what needs to be done. The below is for incoming blocking only (and that's all I'm interested in.)

    Sending server connects to SmarterMail on port 25.

    SmarterMail responds with a 220 message with your official host name.

    Sending server issues HELO/EHLO -- at this point in time SmarterMail traps the IP Address of the sending server and apparently checks whatever SMTP blocking test you have defined and checks the IP Address against any whitelisted IP Addresses, BUT SmarterMail does not block at this point in time.

    SmarterMail responds with the proper HELO or EHLO info.

    Sending server issues MAIL FROM: command and info. SmarterMail logs this info.

    At this point if the sending server IP Address meets blocking critera SmarterMail issues: "554 Sending address not accepted due to spam filter" and closes the connection.

    The very next command the sending server would have sent would be the "RCPT TO:" command and info. If SmarterMail simply waited for the RCPT TO info it could check the "from" address against the Trusted Sender list. The message data has not yet been processed.

    Like it or not valid messages do come from servers on RBL's. Every yahoo, microsoft, gmail, and AOL server has been on the major RBL's. Does that mean you shouldn't accept any messages from the biggest email servers in the world if they are on Spamhaus, or Spamcop, etc? That's silly.

    We're talking about getting about 150 additional bytes (not k or m bytes, just bytes) of data by accepting the RCPT TO info and checking that info against the Trusted Senders.

    Without this you have to make a choice... do you use SMTP Blocking or Trusted Senders? If you use SMTP Blocking then Trusted Senders is worthless.

    A major flaw that could be fixed without ever processing the message data.

    -Joe
  8. ramiss

    ramiss Senior Member

    In order to determine which Trusted sender list is allowing this sender the message, or at least the headers, would have to be processed to determine the recipient. As I mentioned the definition of an SMTP block is to block incoming SMTP connections before they tax the server. Asking for any kind of processing of the server, even if the info is available, defeats the point.

    Did you try what I suggested? It will do what you are asking.
  9. csimo

    csimo Product Expert

    First, you're debating what SMTP blocking should or shouldn't be. I'm not interested in that. I am interested in the way SmarterMail processes the messages.

    No, there would be virtually no additional load on the server compared to the way it works now.

    SmarterMail already processes the MAIL FROM. The only possible data saving would be to refuse to accept the MAIL FROM that is now accepted, but we're talking about a few bytes here, not enough to worry about even if you were operating a server on a dial-up line. The RCPT TO data is no more than the MAIL FROM info already received. This happens the same way on any SMTP server.

    SmarterMail already runs the sending server IP Address against the whitelist. All we need to do is run the MAIL FROM against the Trusted Senders. All of this can be done without processing the Subject or message data.

    Your solution is to not block and process the entire message? Then why bother to enter a discussion of SMTP blocking? Nobody will ever force you to block a message.

    The difference between what SmarterMail already does and what it should do is to accept the RCPT TO information. This does not process the message data at all since it has not yet been sent (and can't be sent until given permission by SmarterMail).

    -Joe
  10. ramiss

    ramiss Senior Member

    Please accept my appologies. I did not mean for this to turn into an argument. Ultimately I think you have a good idea.
  11. csimo

    csimo Product Expert

    Sorry. No argument here either.

    I just get very frustrated with SmarterTools. They'll respond to an end user wanting to know how to configure Outlook, but not to professionals using their products.

    It would be so much easier if I didn't care.

    -Joe
  12. ST-JLance

    ST-JLance New Member

    The reason we reject the mail after the MAIL FROM and not after the RCPT TO is that the 500 error has a different context for each. For the MAIL FROM, it means that the sender is being rejected. For the RCPT TO, it means that the recipient is being rejected. It doesn't seem like much of a distinction, but we tested this pretty thoroughly back when it was implemented in SmarterMail 3.
    Would it be useful to have trusted senders for SMTP blocking? Certainly. Unfortunately, it would make it less effective in the whole.
    In any case, it is recommended that SMTP Blocking should have a high enough weight threshold that there should be false positives.

    In regards to your frustration. I apologize that you feel we respond enough in the forums. But the fact is that this forum exists for our customers to communicate with each other, not as a support forum. We try to answer posts as time allows, but programming has a much greater importance. As such, I tend to answer forums between SmarterMail compiles, which is why I tend to make 30 second answers such as how to configure Outlook.
  13. csimo

    csimo Product Expert

    I appreciate the response.

    So you're saying that if SmarterMail responded with "554 Sending address not accepted due to spam filter" after the RCPT TO the sender bounce message would be different than if the same 554 message was sent after the MAIL FROM?

    I don't know of a way to test this, and I certainly don't know of every mail server in use, but usually the sending server would just bounce the message with the "554 Sending address not accepted due to spam filter". I wasn't aware that a server would change the response.

    This seems very strange since per RFC a 554 is not a valid response to MAIL FROM or RCPT TO anyway.

    Well I'll drop back to my original request... allow us to customize the response codes. At least the 554 so we could provide more info.

    Thanks again for the response.

    -Joe