On 01/20/03 at 12:12, Chris Ellens opined:
> I've been testing SIMS on my LAN for some time now and only recently
> opened port 25 to the scary world out there.
>
> I've also been lurking on this list for some time, so hopefully I've
> learned enough to configure SIMS properly.
>
> But looking at some recent logs, I'm concerned that I might still be
> vulnerable.
>
> 02:16:58 4 SMTP-050() Got connection from [64.169.240.3:1087]
> 02:16:58 4 SMTP(tcp) Connection accepted from [64.169.240.3:1087],
seq=49,
> 1/2
> 02:16:58 4 SMTP-050([64.169.240.3]) Sending 220-fmly.ca Stalker
> Internet Mail Server V.1.8b9d14 is ready.\r\n220 ESMTP is spoken
> here. You are welcome\r\n
> 02:16:58 5 SMTP-050([64.169.240.3]) OT 106 of 106 bytes sent, Flags=0
> 02:16:58 5 SMTP-050([64.169.240.3]) *Status=34
> 02:16:58 4 SMTP-050([64.169.240.3]) Looking for
> 3.240.169.64.relays.osirusoft.com
> 02:16:58 5 SMTP-050([64.169.240.3]) *Status=34
>
> (other relay checks ommitted here). It looks like the sender is not a
> know relay. OK.
Not sure what you think is odd here. SIMS answered an SMTP connection and
queried relays.osirusoft.com to see if the remote host is listed. All
normal.
> 02:16:59 5 SMTP-050([64.169.240.3]) Received 11 bytes
> 02:16:59 4 SMTP-050([64.169.240.3]) Input Line: HELO none\r
> 02:16:59 5 SMTP-050([64.169.240.3]) *Status=21
> 02:16:59 4 SMTP-050(none) Looking for none
> 02:16:59 3 SMTP-050(none) Failed to verify. Real address is
> [64.169.240.3:1087]
> 02:16:59 4 SMTP-050(none) Sending 250 fmly.ca cannot verify none\r\n
> 02:16:59 5 SMTP-050(none) OT 32 of 32 bytes sent, Flags=0
>
> Couldn't verify. Doesn't that mean I shouldn't trust him and SIMS
> should drop the connection? But it accepts a message:
'Couldn't verify' simply means that when SIMS tried to resolve the host
name give in the HELO command, the answer didn't match the remote hosts IP
address. That's not surprising here, since the HELO argument ('none') is
not a name that be resolved. There are lots of legitimate reasons that a
HELO argument would not resolve to the IP address of the remote host, so
'Failed to verify' shouldn't necessarily be taken as evidence of anything
bad. An argument of 'none' doesn't look too good, though.
> 02:16:59 5 SMTP-050([64.169.240.3]) *Status=22
> 02:17:00 5 SMTP-050([64.169.240.3]) Received 37 bytes
> 02:17:00 4 SMTP-050([64.169.240.3]) Input Line: MAIL
> FROM:<[EMAIL PROTECTED]>\r
> 02:17:00 5 SMTP-050([64.169.240.3]) *Status=25
> 02:17:00 5 SYSTEM {S.0000018985} in work, ref=4702, nFresh=4
> 02:17:00 5 ROUTER Input: handsomeguy(hotmail.com)
> 02:17:00 5 ROUTER Parser: [EMAIL PROTECTED] ->
> handsomeguy(hotmail.com)
> 02:17:00 4 ROUTER redirected to email(NULL) (safe)
> 02:17:00 5 ROUTER Input: handsomeguy(NULL)
> 02:17:00 5 ROUTER Parser: handsomeguy@NULL -> handsomeguy(NULL)
> 02:17:00 5 ROUTER Input: NULL()
> 02:17:00 5 ROUTER Parser: NULL -> NULL()
> 02:17:00 4 SMTP-050([64.169.240.3]) Sending 250
> <[EMAIL PROTECTED]> sender accepted\r\n
>
> OK, I confess I'm so paranoid I have the following entry in my
> router: *.com = NULL
That's way overboard paranoid for most set-ups. Since probably a very large
proportion of incoming mail on most servers will have *.com Return-Paths,
routing *.com to NULL will mean that you'll have to add router entries for
any and all specific .com domains that you find acceptable.
> Obviously it has no effect on the sender address.
But it is. The router is routing [EMAIL PROTECTED] to NULL. That
means that SIMS will accept the incoming message, but not deliver it
anywhere. You should find that there are not any log entries subsequent to
the above fragment that indicate that the message was either delivered to a
local account or relayed. If you want messages like this to be bounced
instead of sent off into the ether (bouncing is arguably better), you
should route to 'error' rather than 'null'.
> 02:17:00 5 SMTP-050([64.169.240.3]) OT 47 of 47 bytes sent, Flags=0
> 02:17:00 5 SMTP-050([64.169.240.3]) *Status=23
> 02:17:00 5 SMTP-050([64.169.240.3]) Received 31 bytes
> 02:17:00 4 SMTP-050([64.169.240.3]) Input Line: RCPT
> TO:<[EMAIL PROTECTED]>\r
> 02:17:00 5 ROUTER Input: snowbaby(hotpop.com)
> 02:17:00 5 ROUTER Parser: [EMAIL PROTECTED] -> snowbaby(hotpop.com)
> 02:17:00 4 ROUTER redirected to email(NULL) (safe)
>
> Yes - redirecting to NULL should be safe!
Again, your routing to NULL is working.
> 02:17:00 5 ROUTER Input: snowbaby(NULL)
> 02:17:00 5 ROUTER Parser: snowbaby@NULL -> snowbaby(NULL)
> 02:17:00 5 ROUTER Input: NULL()
> 02:17:00 5 ROUTER Parser: NULL -> NULL()
> 02:17:00 4 SMTP-050([64.169.240.3]) Sending 250 <[EMAIL PROTECTED]>
> Welcome to the Black Hole\r\n
> 02:17:00 5 SMTP-050([64.169.240.3]) OT 53 of 53 bytes sent, Flags=0
>
> Ummm, correct me if I'm wrong, but did I just relay a message to
> "snowbaby"?
Nope. SIMS sent a 250 result code back to the remote host, indicating that
the message was accepted and routed into 'the Black Hole' (i.e. into the
Void). Your routing to NULL is working. 8^)
> I've got "Relay for Clients only" (and only one IP address in the
> clients list). I've got "Verify Return Path" and "Use Blacklist
> Servers". Any elightenment as to how I can better protect my server
> would be appreciated.
With those settings/features enabled it's protected about as well as it's
going to be.
> Part of the reason I'm so paranoid is that a couple days after
> opening up port 25 on my router one of my ISP email addresses
> suddenly got swamped with bounced spam (400 msgs/day). But I've
> checked everything and nowwhere is that email address used anywhere
> in my SIMS configuration. (It was used on a domain registration a few
> years back, though). I assume the incident was just a nasty
> coincidence.
Probably not a coincidence. More than likely, since the address was used in
a domain registration, it got slurped up into one or more spam lists. If
the address is truly not being used, I'd make it into a spamtrap.
--
Christopher Bort | [EMAIL PROTECTED]
Webmaster, Global Homes | [EMAIL PROTECTED]
<http://www.globalhomes.com/>
#############################################################
This message is sent to you because you are subscribed to
the mailing list <[EMAIL PROTECTED]>.
To unsubscribe, E-mail to: <[EMAIL PROTECTED]>
To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]>
To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]>
Send administrative queries to <[EMAIL PROTECTED]>
