> Doesn't the new proposed RFC allow up to 1024 characters? ESMTP commands may have an ever-larger number of bytes as extensions are added. For this reason, ADPHA does not apply its logic to EHLO sessions, only standard SMTP sessions.
> ADPHA IMHO doesn't not prohibit all E/SMTP hack attacks but rather a > known exploit of weaker email servers. Wasn't this to prohibit > client software/hackers injecting multiple DATA command's prior to a > 220 response? It was originally to prevent a number of buffer overflow attacks that are rarely tried these days (yet anyone who's trying them is certainly a black hat). For more latter-day situations, it would prevent a spammer trying to pipeline stuff to your server without a HELO or EHLO or some other out-of-sequence sessions, rare but certainly suspicious occasions. It's crucial to note that the ONLY difference between having ADPHA on and off is that with it on, there will be an automatic blacklist of an offending IP; with it off, any offending command will STILL be rejected by the server with a 552: Command Exceeds Maximum Length, but the session will stay up. So turning it off won't fix a broken session completely, but if a mailer for some reason exceeds the limit, then backs off and retries after the 552 with a shorter command length, the session will be successful. You would see a record of the 552 in your logs either way, and I'm hard pressed to think of a situation in which sending overlength commands, then backing off, is normal. Len's IMGate community has found that when PostFix and IMail communicate at LAN speeds, IMail can detect that overlength commands have been sent and blacklist its own gateway, obviously a bad situation. The question of whether PostFix has a timing issue (not waiting long enough for a response on a socket, waiting too long for a response, things like that) when dealing with the not-the-fastest-card-in-the-deck IMail SMTPD, or whether IMail is seeing phantom overlength commands where there are none, has not been resolved. Len takes the position that PostFix cannot be broken, though he was not aware of what IMail's function actually does until a couple of days ago. In the absence of real evidence, I take the position that the cause of the PostFix alarm is unknown and bears further study, and certainly does not extend to a blanket condemnation of the IMail feature. > Also, Is it good or bad to check/uncheck the ADPHA box and why? I don't think there's anything wrong with checking the box if your IMail server is published on the Internet and is not in a situation that is known to set off the alarm for currently unknown reasons (that is, on the same segment as PostFix). It's a bit of host-based security that, as I mention, is already in place anyway (only the proactive blacklisting can be turned on or off) and has been in IMail for a long time, a default that is active in tens of thousands of installations. -Sandy To Unsubscribe: http://www.ipswitch.com/support/mailing-lists.html List Archive: http://www.mail-archive.com/imail_forum%40list.ipswitch.com/ Knowledge Base/FAQ: http://www.ipswitch.com/support/IMail/
