On Thu, 21 Nov 2002, T. Mike Howeth wrote:
>
> First, a bug: Base64Enc.cpp: decode64() references two bytes of data
> before validating that the passed text is at least that long. To fix,
> add:
> if (inlen>1)
> before the existing code, which begins:
> if (in[0]=="+" && in[1]==' ')
Yep, this is in 1.12
> Also, errors are mis-handled in SMTPHandleCmd_DATA(), causing the wrong
> error number to propagate up to the caller. Because this only occurs
> when some error has occurred, it has apparently gone unnoticed, but is
> evident if you try to return an error other than the one that the
> distributed 1.10 release returns. The existing code is not affected by
> this defect in any way (but I had to address it to implement the content
> filter described below).
> In the case of SMTPHandleCmd_DATA(), the problem can be overridden near
> the end of where the code calls ErrorPush(), then does some things, then
> does iErrorCode=ErrorPop(). Fixed by changing the pop to:
> ErrSetErrorCode(iErrorCode=ErrorPop()). This still does not address
> issues with the handling of pszSmtpError, however. Error handling in
> this and related functions is imprecise and really needs to be
> overhauled, as pszSmtpError and iErrorCode (and the error code set by
> ErrSetErrorCode()) are frequently not handled as a unit and can end up
> disagreeing with each other (e.g., the error code comes from one error,
> but the message from another). If a custom error message can be used,
> then clearly ErrSetErrorCode(), ErrPush() and ErrPop() must handle not
> only the error number, but the error message string as well.
> Additionally, ErrPush() and ErrPop() really should implement an actual
> stack instead of using a single variable. Left as-is, their names imply
> that they can be used to safely store the current error condition across
> calls to other arbitrary functions, when in fact they cannot.
No because :
1) SMTP error codes does not map 1 == 1 to XMail internal error codes
2) The error push/pop are only meant to protect the cleanup code after an
error. Yes it is possible that the error returned by
ErrGetErrorCode() is different from the one that really caused the
error deep down in the code, like "errno" might be checnged if you
get other errors in your cleanup path.
> does not display the program name or version # on server banners.
> Display of this information offers no advantage to a standards-based
> service, and informs the world exactly which bugs you have.
This has been discussed a lot of times and I'm kind of sick to repeat the
same things. Anyway, this :
$ telnet 66.13.123.62 80
HTTP/1.1 403 Forbidden
Content-Length: 218
Content-Type: text/html
Server: Microsoft-IIS/6.0
PICS-Label: (PICS-1.0 "http://www.rsac.org/ratingsv01.html"; l on
"2002.11.05T19:17-0600" exp "2003.11.05T12:00-0600" r (v 4 s 4 n 4 l 4))
Date: Fri, 22 Nov 2002 02:42:44 GMT
Connection: close
tells me that you should better have different worries but the SMTP
server. Since I'm a wizard :) I can tell you that you're running
Windows on an Ix86 CPU. Am I wrong ? Let's do this. The next time XMail
will have an exploitable buffer overflow vulnerabily, I'll change this.
> The verbiage of most server result messages is changed. This is largely
> nothing more than a matter of taste, but at least one typo is corrected
> as well.
Please send me everything that is not taste-dependent and I'll take a
look.
> the response sent if the VRFY command is disabled is "252 Argument not
> checked" per RFC 2505
This is true actually, even if returning a 2xx class error does not
exactly match the permission denied kind of thing.
> server.tab changes
>
> CheckMailerDomain
> 0: do not check
> 1: check; on failure, refuse message
> >1: check; on failure, introduce command delay of (value) seconds
> between subsequent commands
No, this makes no sense because it's not session dependent.
> new variables:
> MTABanMessage (string) - message emitted if the sending MTA is
> banned (by a spammers.tab entry)
1.12 == "SmtpMsgIPBanSpammers"
1.12 also "SmtpMsgIPBanMaps" when the abort came from Maps ( the name of
the map is appended to the message )
> SenderBanMessage (string) - message emitted if the sender is banned
> (by a spam-address.tab entry)
> These can be used to emit a message that includes an email address
> (that will accept mail from the sender) to which bans can be contested.
1.12 == "SmtpMsgIPBanSpamAddress"
> ContentViolationsFatal (bool) - determines whether a message
> rejected by the content filter results in a fatal (5xx) error, or a
> transient (4xx) error. the latter causes spammers to retain mail on
> their system until their configured retry time elapses. Normally I
> wouldn't do something like this that intentionally forces an MTA to
> retain the message with no hope of ever delivering it, but I decided
> that spammers can kiss my 4xx.
> ContentViolationMessage (string) - message sent if a message is
> rejected by the content filter (default='Message refused')
> ContentFilterLines (int) - # of message lines across which a content
> filter entry checks for forbidden content. 0=disable content filtering,
> 1=line by line, >1=examine message using an n-line window.
> ContentFilterLocalMail - (bool) 0=mail from local users is not
> subjected to the content filter. I will be changing this shortly to use
> a config file for exemptions instead of this flag.
No, this is filter related stuff. It won't go in.
> SMTP log file changes
> added ClientFQDN: result of SMTP-RDNSCheck lookup
Ok, it is in 1.12 as the last field of the SMTP log
> New configuration file filtcontent.tab: Message content filter -
> rejects messages (including base64-encoded messages) based on their
> content (see server.tab variables ContentViolation*, ContentFilter*)
No. See above.
- Davide
-
To unsubscribe from this list: send the line "unsubscribe xmail" in
the body of a message to [EMAIL PROTECTED]
For general help: send the line "help" in the body of a message to
[EMAIL PROTECTED]
