Coping with hotmail's new slow servers

FWIW, spammers can setup SPF, so I would say that greylisting + SPF is at least desirable for many users.
Perhaps it could be an option though.

Barry

FWIW, spammers can setup SPF, so I would say that greylisting + SPF is at least desirable for many users.
Perhaps it could be an option though.

Barry

Barry, 
 
Yes I agree everything should always be optional...

As to the spammers creating SPF's, can you explain how that would work? Microsoft owns the records for the nameservers that control hotmail. ie:

[SIZE="2"][FONT="Courier New"]hotmail.com. 171588 IN NS ns1.msft.net.
hotmail.com. 171588 IN NS ns2.msft.net.
hotmail.com. 171588 IN NS ns3.msft.net.
hotmail.com. 171588 IN NS ns4.msft.net.
hotmail.com. 171588 IN NS ns5.msft.net.[/FONT][/SIZE]

How could a spammer add SPF records to the servers microsoft controls. I've avoided learning the details of SPF's until now; but I think SPF is just a special TXT record in the DNS server that is query via command like 

[SIZE="2"][FONT="Courier New"]$dig hotmail.com TXT

; <>> DiG 9.4.2-P2 <>> hotmail.com TXT
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<>> DiG 9.4.2-P2 <>> spf-a.hotmail.com TXT
;; global options:  printcmd
;; Got answer:
;; ->>HEADER

The reason I don't configure SPF is that it gets false positives on forwarded mail.  I removed it from all my clients.  I figure that the ASGs have to work a little harder, but I don't think any more spam gets through.

I've been hesitant to use Greylisting at large clients because so much email is time-sensitive.  Do you find that there are very many rejections with it?  Would it work to turn it on in off-hours during the first few days to build up the database, or does the Astaro erase the database when Greylisting is turned off?

Thanks - Bob

We've used greylisting of various sorts since it came on the scene a few years back. I find the astaro implementation usable; but it has a few flaws. You have to be aware of.

To your direct question you could use off hours for training but results will be spotty as most business email occur during the day.

95% of business email is going to come from good fast proper RFC behaving mail servers. Greylisting causes issues with: (i) big slow overloaded email servers with HUGE retry queues from thousands of users. (ii) big slow spam relaying servers with lots of virus ladden residential customers. (iii) large services with huge clusters of servers that don't mask behind flat ip and doing rolling retries. If you exempt the big houses by know IP Network for Gmail; Hotmail; and AOL you can remove most noticeable delays; as those services are the most likely to have Valid long retry queues.

The features missing from the astaro greylist are mostly option/behavior tweaks including:

1) Adjustable Length of time a valid entry is cached in the database; as we've found that 6 months is a nice time frame to keep a valid IP/Sender/Recpt pair around. In buisness it's common to have key customers silent for that long. I have a few customer with the proxmia filters that run 18 months.

2) Enduser Whitelisting addresses and the greylist filter doesn't work as it should. Sometimes it works sometime it doesn't

3) SPF should allow the greylister to be bypassed.

4) You should be able to pick a mode that just does Sender/Recpt pairing as this has less false positives than IP/Sender/Recpt and will make nervous customers happier. Mostly this solves problems with big shops using clusters where the retry emails comes from another machine.

4a) RealTime Whitelist servers. All RWL to be used and have anyone on a RWL optionally either: (i) auto pass the filter or (ii) only greylist by Sender/Recpt pairs and not IPs

5) It needs a learning mode; where you can turn it on; but not have the rejections/faked failures happen; basically do everything as normal but skip the rejects; that way people that communicate more than once a day will quickly pre-populate into the database; but the user would be unaffected. Then you could deploy; train for 2 weeks and activate and have far less pain.

6) It needs an auto-whitelist on send option. So that if you send an outbound email to a person; that person is automatically put on the white list. I'm pretty sure it doesn't do that but someone might need to check; I've only done deep analysis on our inbound hub units.

7) Stats about what the greylister is up to; the only way to analyze the greylister is to read the raw log files and I think that's why a lot of people turn it off.

In the end BATV, SPF and Greylisting are really nice and powerful feature but I've noted over time that they spook alot of people.

As to your SPF problem try turning if off; I think you'll find it doesn't trip on forward emails any more. It will choke on the occasional; I use my home ISP smtp server and my work address; but really those people should being doing that now should then  [:)]   and sometimes it's nice to be  TBOFM

I've been hesitant to use Greylisting at large clients because so much email is time-sensitive.  Do you find that there are very many rejections with it?  Would it work to turn it on in off-hours during the first few days to build up the database, or does the Astaro erase the database when Greylisting is turned off?

Thanks - Bob

As to the spammers creating SPF's, can you explain how that would work? 

Hopefully not in the case of hotmail, but any of the following can (and do) happen:

1. legitimate domain
a. valid SPF
  misconfigured mail server or infected internal PC allows relays
b. misconfigured SPF

2. spammer buys domain, sets up valid SPF. This is happening a lot.

3. shared hosting, etc. create additional problems.
see http://en.wikipedia.org/wiki/Sender_Policy_Framework#Caveats for more info.

Barry

1) Adjustable Length of time a valid entry is cached in the database; as we've found that 6 months is a nice time frame to keep a valid IP/Sender/Recpt pair around. In buisness it's common to have key customers silent for that long. I have a few customer with the proxmia filters that run 18 months.

Ratz: FYI, Astaro recently increased the Greylisting cache time from 1 week to 1 year.  AFAIK it's still a static (non-adjustable) setting, but much improved in this regard.

I too have been nervous about missing e-mails when using greylisting.  But in checking the logs on multiple Astaro's I've found that greylisting bounces are not triggered too often.  Nonetheless, it does work when needed.

I have elected to not implement greylisting in situations, such as retail, where the e-mailers change all the time and often never e-mail more than a few times.  But for regular office settings, it's always good to have another tool for the SPAM wars.  And I've yet to get a complaint about missing e-mail that's due to the Astaro's greylisting option.

1) Adjustable Length of time a valid entry is cached in the database; as we've found that 6 months is a nice time frame to keep a valid IP/Sender/Recpt pair around. In buisness it's common to have key customers silent for that long. I have a few customer with the proxmia filters that run 18 months.

Ratz: FYI, Astaro recently increased the Greylisting cache time from 1 week to 1 year.  AFAIK it's still a static (non-adjustable) setting, but much improved in this regard.

I too have been nervous about missing e-mails when using greylisting.  But in checking the logs on multiple Astaro's I've found that greylisting bounces are not triggered too often.  Nonetheless, it does work when needed.

I have elected to not implement greylisting in situations, such as retail, where the e-mailers change all the time and often never e-mail more than a few times.  But for regular office settings, it's always good to have another tool for the SPAM wars.  And I've yet to get a complaint about missing e-mail that's due to the Astaro's greylisting option.