Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 8 replies
  • Subscribers 1 subscriber
  • Views 5371 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Use of 'Reject at SMTP Time'

BAlfson
Yesterday, I looked at our spam report and saw that we had no blackholes, only rejects.  Prior to V7, we never configured "Reject" in order to not give out information about who was a valid recipient.  Apparently, in the transition to V7, this was turned on, probably explicitly by me, not thinking that "Reject" meant "reject" - doh!  I've just set this to "Off" as our box has plenty of left-over cycles to run these emails through the spam+virus filters.

Does anyone know which features this turns off?  For example, will it still 'Reject invalid HELO / missing RDNS', incorrect BATV and/or SPF?

Is there a good reason to NOT offer an option for 'Blackhole at SMTP Time'?

Thanks - Bob


This thread was automatically locked due to age.
Parents
  • 0
    Howdy BAlfson,
    I have the same problem, and now backscatter is becoming a huge problem for us.
    Anyone in doubt can try the following on a 220 or 320 or whatever astaro running 7.306 r 7.402 .You'll see the astaros ARE VULNERABLE to spam relaying .  And there is only one solution, astaro needs to add a feature to Disable Bounced messages Y,N
    Backscatterer.org powered by UCEPROTECT
    try the following anyone... at a prompt telnet mail.mydomain.com 25 
    then do the HELO jerry.aol.com {enter} then MAIL FROM: Victim@victimdomain.com {enter}, then RCPT TO: nosuchuser@yourdomainbehindastaro.com
    astaro WILL ACCEPT THE EMAIL,  then generate a bounce and mail the email to the victim.  Astaro needs to fix this.  I can't sell astaros to our bank customers due to Astaros failing Qualys and darned near any other vulnerability scanner testing.  Hope astaro fixes it.  Someone with a few days can call /report this to astaro.  Thanks to all who help on the forum.  It's our best wayof getting support.
Reply
  • 0
    Howdy BAlfson,
    I have the same problem, and now backscatter is becoming a huge problem for us.
    Anyone in doubt can try the following on a 220 or 320 or whatever astaro running 7.306 r 7.402 .You'll see the astaros ARE VULNERABLE to spam relaying .  And there is only one solution, astaro needs to add a feature to Disable Bounced messages Y,N
    Backscatterer.org powered by UCEPROTECT
    try the following anyone... at a prompt telnet mail.mydomain.com 25 
    then do the HELO jerry.aol.com {enter} then MAIL FROM: Victim@victimdomain.com {enter}, then RCPT TO: nosuchuser@yourdomainbehindastaro.com
    astaro WILL ACCEPT THE EMAIL,  then generate a bounce and mail the email to the victim.  Astaro needs to fix this.  I can't sell astaros to our bank customers due to Astaros failing Qualys and darned near any other vulnerability scanner testing.  Hope astaro fixes it.  Someone with a few days can call /report this to astaro.  Thanks to all who help on the forum.  It's our best wayof getting support.
Children
  • 0 in reply to RDL
    None of my clients have the problem you're complaining about.  As long as their mail server can be configured to reject at SMTP time, so can the Astaro.

    Cheers - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0 in reply to BAlfson
    @balfson, Reject during SMTP transaction can be used for AV detection as well as spam detection - the option is on both tabs. If the av engine or the spam detection engine flags the message while the smtp transaction is in progress, then we can reject the message with a 500 range error, and not send an NDR. This means that the sending server is now responsible for notifying the sender of the failure. if this is a spammer, then there is no NDR to be sent. If it is a legitimate server, then an NDR will be sent from the sending server to the original sender, which is desirable behavior, as you mention above. This is separate from rDNS/HELO,SPF, BATV etc.. checks. Those are not affected by this option.

    @RDL, The vulnerability you talk about is a mail server issue, not an Astaro issue. Astaro will only accept mail to nosuchuser@yourdomainbehindastaro.com if the mail server behind the Astaro is willing to accept mail for that recipient. Therefore, Astaro accepts and successfully forwards the message to the mail server. It would then be the mail server generating the NDR, not the Astaro. If the mail server uses recipient verification, then Astaro will reject the message during the SMTP transaction, not generating an NDR. If you are using an older exchange server which does not support recipient verification, Asaro can also do recipient verification over LDAP. Further, RBLs, rDNS/HELO checks, greylisting, and IP reputation checks already help prevent against this kind of attack actually being carried out - even if your mail server is unable to support RV.
  • 0 in reply to AlanT_01
    *AlanT  reports that this is not an astaro issue, because "Astaro will only accept mail to nosuchuser@yourdomainbehindastaro.com if the mail server behind the Astaro is willing to accept mail for that recipient."
    However this is not true.  astaro accepts mails first the ask the mail serve if the user is there..
    just try to telnet to your server, send an mail and astaro will accept even if the user is unknown.

    anyone fixed the problem with ending up in the backscatter black list ?
Unfiltered HTML