Hello, on 21.01.2003 00:02, Global Homes Webmaster at
[EMAIL PROTECTED] wrote:
> 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.
Not like that. The message will be accepted and delivered. But the server
won't be able to send to any *.com domain with that router records in place
- all the _outgoing_ messages will be discarded silently.
> 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.
--
Best regards,
Dmitry Akindinov
=======================================================================
When answering to letters sent to you by the tech.support staff, make
sure the original message you have received is included into your reply.
#############################################################
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]>
