Re: SMTP logging

I bet it wouldn't be a problem with essentially any kind of internal monitoring report imaginable, with the exception of a spam report email, which will make IMF automatically apply an 8 to it and archive it if the IP is not on the right list in the right way. The various list combinations make my head hurt, but originally I didn't even have the Connection Filter (or Sender ID) enabled so had nothing in General (Perimeter list), which only applies to those two. In that scenario, with just IMF enabled, IMF will hold a spam report every time.

So then I investigated the problem and through that article found that it was the Accept List in Connection Filtering that allows you to make IMF host exceptions. If there's another way, I'd like to know. So I had no choice but to enable Connection Filtering and configure the Accept List, which set up the problem when you also configure General (Perimeter list) in order for Sender ID to work, since when you have both enabled with the same IP the Accept List is ignored.

On 7519, for the brief time I had Sender ID enabled, I saw one of those in Event Viewer, and we don't use the POP connector. I was going to say it was from an email with a spoofed IP, but then I saw that the email in question was an automated report sent internally here via SMTP. Sender ID should know the server's own IP very well, but it may be that the IP is not included in the header of internal mails, which is the crux of the error.

"Dave Nickason [SBS MVP]" <gwdibble@xxxxxxxxxxxxxxxxxxxxxx> wrote in message news:#Rq0kwVDKHA.3708@xxxxxxxxxxxxxxxxxxxxxxx
I'll admit to being something less than an expert on this, but I don't see any reason why an internal IP would need to be on the Connection Filtering accept list. The way I'm interpreting all of this is that if an IP is on the list (Message Delivery Properties -> General), that IP bypasses Connection and Sender ID filtering. Therefore, since your internal address range would be on the Perimeter IP List, there wouldn't be any reason to include an internal IP on the accept list. And, if it's not on the accept list, you won't have the problem described in the article.

I get e-mails from various monitoring functions on 3 servers in addition to my SBS, and I know those are all arriving as expected. Other than that, I do get about a dozen 7519 errors in my application log indicating that the originating IP could not be determined. I haven't put much time into figuring that out, but I do have an old account that uses the POP connector, so I'm wondering if it's the POP messages that are triggering that error.


"Milhouse Van Houten" <btvs@xxxxxxxxxxxxx> wrote in message news:eW3fuEPDKHA.4376@xxxxxxxxxxxxxxxxxxxxxxx
That level of SenderID looks worthwhile. I looked into enabling it, but it requires that you put your IP into the General tab of Message Delivery, which is all well and good until you realize that it then negates the IP in the Connection Filtering Accept list (due to the unfortunate issue at the link), which is necessary so that internally generated SMTP emails are not subject to flagging. That's more important than SenderID for us, so it won out. I could get around it with a second NIC and a second virtual server, but it's not worth it. How did you avoid the issue?
http://www.exchangeinbox.com/article.aspx?i=44&t=3&all=1

Creating an SPF record, which sounds like it's independent of the above, looks interesting too:
http://www.microsoft.com/mscorp/safety/content/technologies/senderid/wizard/default.aspx

"Dave Nickason [SBS MVP]" <gwdibble@xxxxxxxxxxxxxxxxxxxxxx> wrote in message news:O6f#VnHDKHA.4692@xxxxxxxxxxxxxxxxxxxxxxx
I recently implemented Sender ID but just in the default "Accept" configuration. That means the Sender ID status gets attached to the message for processing by the IMF - it just adds another bit of information for the IMF to consider. I agree with you 100% that using "Delete" or "Reject" would be a problem. We have a lot of clients who use their ISP's e-mail or that of a 3rd party, where the sender has no control over the configuration of their mail server. It would be unacceptable to us not to be able to receive messages because of something beyond the sender's control.

FYI, I can't really say one way or the other that Sender ID is reducing the amount of Spam. It seems like it must be, but I'm still seeing some messages I'd have expected to be rejected.

I use the Spamhaus ZEN blocklist, which I've been happy with when combined with the IMF. I get a little more spam than I'd like, but I'm not getting complaints from clients that their messages are blocked, which is an important consideration for us. I'd probably use an external filtering service like Exchange Defender (which I'm considering, actually), but I'll stick with what I'm doing until/unless I start getting more vocal user complaints.



"Milhouse Van Houten" <btvs@xxxxxxxxxxxxx> wrote in message news:u7l%23qtADKHA.4792@xxxxxxxxxxxxxxxxxxxxxxx
Dave, do you find it practical to use Sender ID? Wouldn't it take just one or two parties not supporting it to become a problem pretty quickly? And do you have a reliable RBL to recommend? So far, just IMF seems to be doing the job for me.

"Rob C" <RobC@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message news:CBD26DC1-FC45-4DCC-8C50-F344D74200B5@xxxxxxxxxxxxxxxx
Excellent Dave, that's kick ass!
Just what I wanted to find out.
At the moment out of the DNS queries issued to RBL's, almost half are being
nuked.
Wow.
With this info I can hopefully fine-tune my RBL list to see what give the
best return.

thanks again.

"Dave Nickason [SBS MVP]" wrote:

It's not an answer to your question, but FYI you can performance monitor the
Transport Filter Sink, which includes RBL, sender and recipient filtering,
etc. Also Sender ID and IMF. Post back if you want the 50 cent tour - the
short answer is to open Administrative Tools -> Performance and add all the
counters for "MSExchange Intelligent Message Filter," "MSExchange Sender
ID," and "MSExchange Transport Filter Sink." It won't take you long to see
which counters you want to delete - some of them aren't very relevant to an
SBS-sized domain, such as messages rejected per second.

The counters show statistics starting with the last time Exchange started
(usually the last reboot). You'll be amazed at how many connections the RBL
rejects, and how many messages fail Sender ID.


"Rob C" <RobC@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:88CA33EE-A0F5-4443-83BA-579C2AADB597@xxxxxxxxxxxxxxxx
> my apologies; CRIS
>
> "Rob C" wrote:
>
>> Chris thanks.
>>
>> The NDR generated from an RBL produces a 5.7.1 code am I right?
>> It would be very useful to actually see what emails do get blocked >> from
>> where.
>>
>> I shall investigate further.
>>
>> "Cris Hanna [SBS - MVP]" wrote:
>>
>> > Not really...from what I could find on a quick google search
>> > The log will only show an error 500 but not all error 500s are >> > the
>> > result of RBL actions
>> >
>> > This link may help some
>> > http://mostlyexchange.blogspot.com/2007/12/enabling-smtp-protocol-logging-for.html?wwparam=1248283756
>> >
>> > -- >> > Cris Hanna [SBS - MVP]
>> > Co-Contributor, Windows Small Business Server 2008 Unleashed
>> > http://www.amazon.com/Windows-Small-Business-Server-Unleashed/dp/0672329573/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1217269967&sr=8-1
>> > Owner, CPU Services, Belleville, IL
>> > A Microsoft Registered Partner
>> > ------------------------------------
>> > MVPs do not work for Microsoft
>> > Please do not submit questions directly to me.
>> >
>> > "Rob C" <RobC@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
>> > news:15D7C6C8-4357-44C6-99C5-48DE5AD14CE2@xxxxxxxxxxxxxxxx
>> > SBS2003R2 Exchange SP2
>> >
>> > I have just turned this feature on and would like to know if >> > it logs
>> > RBL
>> > blocked attempts?
>> >
>> > Thanks!




.

Relevant Pages

  • Re: SMTP logging
    ... the headers from the monitoring ones sent internally do have the IP of the sending server in the headers. ... The various list combinations make my head hurt, but originally I didn't even have the Connection Filter (or Sender ID) enabled so had nothing in General, which only applies to those two. ... So then I investigated the problem and through that article found that it was the Accept List in Connection Filtering that allows you to make IMF host exceptions. ...
    (microsoft.public.windows.server.sbs)
  • Re: SMTP logging
    ... And nothing seems "non-standard" about the headers I examined other than not having Internet routing. ... The various list combinations make my head hurt, but originally I didn't even have the Connection Filter (or Sender ID) enabled so had nothing in General, which only applies to those two. ... So then I investigated the problem and through that article found that it was the Accept List in Connection Filtering that allows you to make IMF host exceptions. ...
    (microsoft.public.windows.server.sbs)
  • Re: SMTP logging
    ... The various list combinations make my head hurt, but originally I didn't even have the Connection Filter (or Sender ID) enabled so had nothing in General, which only applies to those two. ... In that scenario, with just IMF enabled, IMF will hold a spam report every time. ... So then I investigated the problem and through that article found that it was the Accept List in Connection Filtering that allows you to make IMF host exceptions. ...
    (microsoft.public.windows.server.sbs)
  • Re: SMTP logging
    ... I'll admit to being something less than an expert on this, but I don't see any reason why an internal IP would need to be on the Connection Filtering accept list. ... The way I'm interpreting all of this is that if an IP is on the list, that IP bypasses Connection and Sender ID filtering. ... That means the Sender ID status gets attached to the message for processing by the IMF - it just adds another bit of information for the IMF to consider. ... And do you have a reliable RBL to recommend? ...
    (microsoft.public.windows.server.sbs)
  • Re: IMF and SCL values
    ... The closest available thing is the Connection Filtering IP Accept List. ... the senders to be whitelisted have their emails coming from the same IPs, ... Since you are having many false postives, did you enable IMF updates? ... However if a user has been added as a safe sender in outlook ... ...
    (microsoft.public.exchange.admin)
Loading