Greylisting issue
Joey
I have noticed a few people complaining that hotmail, gmail, aol and msn
messages aren't making it through to them.
Apparently when the sending server retries to send mail because of
greylisting, it may come from a different source IP, which breaks the
triplet of information.
Is there anything we can do to get around this? I would hate to kill
greylisting it works great.
Thanks!
Joey
Jan 18 15:38:21 pluto tumgreyspf[6336]: Initial greylisting:
REMOTEIP="64.233.184.232" HELO="wr-out-0506.google.com"
SENDER="test.a...@gmail.com" RECIPIENT="julio...@bartonggg.com"
QUEUEID=""
Jan 18 15:38:21 pluto postfix/smtpd[3694]: NOQUEUE: reject: RCPT from
wr-out-0506.google.com[64.233.184.232]: 450 4.7.1
<julio...@bartonggg.com>: Recipient address rejected: Service unavailable,
greylisted (http://projects.puremagic.com/greylisting/).;
from=<test.a...@gmail.com> to=<julio...@bartonggg.com> proto=ESMTP
helo=<wr-out-0506.google.com>
Jan 18 15:44:39 pluto postfix/smtpd[5586]: NOQUEUE: reject: RCPT from
wr-out-0506.google.com[64.233.184.239]: 450 4.7.1
<julio...@bartonggg.com>: Recipient address rejected: Service unavailable,
greylisted.; from=<test.a...@gmail.com> to=<julio...@bartonggg.com>
proto=ESMTP helo=<wr-out-0506.google.com>
Ralf Hildebrandt
> Apparently when the sending server retries to send mail because of
> greylisting, it may come from a different source IP, which breaks the
> triplet of information.
Usually these greylisting daemons have a "relaxed" mode of operation,
which doesn't look at the exact IP, but the Class C subnet!
--
Ralf Hildebrandt (Ralf.Hil...@charite.de) pl...@charite.de
Postfix - Einrichtung, Betrieb und Wartung Tel. +49 (0)30-450 570-155
http://www.arschkrebs.de
Like medieval peasants, computer manufacturers and millions of users
are locked in a seemingly eternal lease with their evil landlord, who
comes around every two years to collect billions of dollars of taxes
in return for mediocre services. --Mark Harris, Electronics Times
Joey
* Joey <Jo...@Web56.Net>:
> Apparently when the sending server retries to send mail because of
> greylisting, it may come from a different source IP, which breaks the
> triplet of information.
Usually these greylisting daemons have a "relaxed" mode of operation, which
doesn't look at the exact IP, but the Class C subnet!
We do have that relaxed mode on based on the below, however in our example
it didn't really work. Anything else we can do? I would hate to trash
greylisting.
# If set to 1, the last byte of the sender's IP address will be ignored.
# So, if mail from 1.2.3.4 was delayed, then redelivered by 1.2.3.58,
# the message would be accepted as if it came from the same server.
# This allows pools of mail servers to appear as one, increasing
# compatibility with large email services.
ignoreLastByte = 1
Michael Wang
> Hi Everyone,
>
> I have noticed a few people complaining that hotmail, gmail, aol and msn
> messages aren't making it through to them.
>
> Apparently when the sending server retries to send mail because of
> greylisting, it may come from a different source IP, which breaks the
> triplet of information.
>
> Is there anything we can do to get around this? I would hate to kill
> greylisting it works great.
Some greylisting programs like SQLgrey have built-in white-listing
mechanisms. If that's not an option you can follow Ralf's example for
setting up selective greylisting by defining a restriction class at:
http://www.arschkrebs.de/postfix/postfix_greylisting.shtml
except in your case you would use it to do the white-listing for you.
As a trivial example you could do something like this in your pcre file:
# Bypass greylisting for major mail sites
/gmail.com/ OK
/aol.com/ OK
/msn.com/ OK
/hotmail.com/ OK
# everything else greylist
/^.*/ greylisting
--
Michael Wang
Michael Wang
> Some greylisting programs like SQLgrey have built-in white-listing
> mechanisms. If that's not an option you can follow Ralf's example for
> setting up selective greylisting by defining a restriction class at:
>
> http://www.arschkrebs.de/postfix/postfix_greylisting.shtml
>
> except in your case you would use it to do the white-listing for you.
>
> As a trivial example you could do something like this in your pcre file:
>
> # Bypass greylisting for major mail sites
> /gmail.com/ OK
> /aol.com/ OK
> /msn.com/ OK
> /hotmail.com/ OK
>
> # everything else greylist
> /^.*/ greylisting
I forgot to mention that doing something as simplistic as my above
example is likely to let a lot of spam through since so many spam
messages have forged From: addresses from the above sites so you
probably want to be more specific in picking out the mailer domains than
what I listed above.
--
Michael Wang
Sahil Tandon
>> # Bypass greylisting for major mail sites
>> /gmail.com/ OK
>> /aol.com/ OK
>> /msn.com/ OK
>> /hotmail.com/ OK
>>
>> # everything else greylist
>> /^.*/ greylisting
>
> I forgot to mention that doing something as simplistic as my above
> example is likely to let a lot of spam through since so many spam
> messages have forged From: addresses from the above sites so you
> probably want to be more specific in picking out the mailer domains than
> what I listed above.
Right. Instead, he should OK the connecting client IP/hostname. In
postgrey, Google's outbound MXs are whitelisted with:
/^.*-out-.*\.google\.com$/
--
Sahil Tandon <sa...@tandon.net>
Michael Wang
Yeah I poked around at how SQLgrey handles this problem and its
whitelisting seems incomplete so I guess I'll need to fix this up myself.
There's a nice page for AOL referenced in one of the SQLgrey whitelist
files:
http://postmaster.aol.com/servers/imo.html
but SQLgrey only whitelists some of those IPs.
Hotmail and MSN apparently use mx1- mx4.hotmail.com (each of which
resolves to multiple IPs) but SQLgrey is not whitelisting any of the
domains (haven't checked the IPs yet).
Google doesn't publish Google's/Gmail's outbound servers but SQLgrey has
the pattern match as "64.233.170" which doesn't look right (e.g.
nz-out-0506.google.com [64.233.162.236] came from a recent Gmail
message), so that's potentially a problem and may explain why I'm
missing some messages from the Google Group I subscribe to.
--
Michael Wang
Sahil Tandon
> Hotmail and MSN apparently use mx1- mx4.hotmail.com (each of which
> resolves to multiple IPs) but SQLgrey is not whitelisting any of the
> domains (haven't checked the IPs yet).
According to my logs, Hotmail seems to retry from the same server and
maintain the greylist triplet.
> Google doesn't publish Google's/Gmail's outbound servers but SQLgrey has
> the pattern match as "64.233.170" which doesn't look right (e.g.
> nz-out-0506.google.com [64.233.162.236] came from a recent Gmail
> message), so that's potentially a problem and may explain why I'm
> missing some messages from the Google Group I subscribe to.
Using something similar to postgrey's Google ruleset fixes that problem.
--
Sahil Tandon <sa...@tandon.net>
Geert Hendrickx
> Right. Instead, he should OK the connecting client IP/hostname. In
> postgrey, Google's outbound MXs are whitelisted with:
>
> /^.*-out-.*\.google\.com$/
So spammers should simply set their reverse DNS to something like that to
bypass your greylisting?
Reverse hostnames (like anything else that can be forged) should be used
only for blacklisting, not whitelisting.
Geert
Ralf Hildebrandt
> On Thu, Jan 18, 2007 at 09:12:38PM -0500, Sahil Tandon wrote:
> > Right. Instead, he should OK the connecting client IP/hostname. In
> > postgrey, Google's outbound MXs are whitelisted with:
> >
> > /^.*-out-.*\.google\.com$/
>
> So spammers should simply set their reverse DNS to something like that to
> bypass your greylisting?
That's not sufficient with postfix, since postfix ONLY considers a
hostname valid if the forward and reverse lookups match.
--
Ralf Hildebrandt (Ralf.Hil...@charite.de) pl...@charite.de
Postfix - Einrichtung, Betrieb und Wartung Tel. +49 (0)30-450 570-155
http://www.arschkrebs.de
Dirty hack? Did someone call my name?
Cami
> On Thu, Jan 18, 2007 at 09:12:38PM -0500, Sahil Tandon wrote:
>> Right. Instead, he should OK the connecting client IP/hostname. In
>> postgrey, Google's outbound MXs are whitelisted with:
>>
>> /^.*-out-.*\.google\.com$/
>
> So spammers should simply set their reverse DNS to something like that to
> bypass your greylisting?
Postfix verifies the forward and reverse to ensure they match.
Cami
Geert Hendrickx
> > So spammers should simply set their reverse DNS to something like that
> > to bypass your greylisting?
>
> That's not sufficient with postfix, since postfix ONLY considers a
> hostname valid if the forward and reverse lookups match.
Right, I forgot that.
Geert
Sahil Tandon
>> Right. Instead, he should OK the connecting client IP/hostname. In
>> postgrey, Google's outbound MXs are whitelisted with:
>>
>> /^.*-out-.*\.google\.com$/
>
> So spammers should simply set their reverse DNS to something like that to
> bypass your greylisting?
Incorrect.
--
Sahil Tandon <sa...@tandon.net>
Kevin Bailey
I need to move the hosting of email of several domains from one server
to another. This second email server will have a different IP address -
due to the server farm being different I can not use the existing
server's IP address.
Say all mail is being directed to an address such as mail2.example.com.
Is all I have to do is:
* Set up new server so it is ready to receive email for the domains.
* Turn off existing server.
* Synchronise all existing email over to the new server using rsync or
similar.
* Change DNS record for mail2.example.com to point to the new server's
IP address.
* Wait and as the new IP address is distributed the mail will start
arriving at the new server.
Thanks for any pointers or watchout's.
Kevin
Miles Fidelman
> I need to move the hosting of email of several domains from one server
> to another. This second email server will have a different IP address
> - due to the server farm being different I can not use the existing
> server's IP address.
>
> Say all mail is being directed to an address such as mail2.example.com.
>
> Is all I have to do is:
this well in advance of the cutover
>
> * Set up new server so it is ready to receive email for the domains.
> * Turn off existing server.
> * Synchronise all existing email over to the new server using rsync or
> similar.
- turn of the existing server for a very short time
- synchronize existing mail
- modify the config of your current server so that it forwards incoming
mail to the new server
- restart old server
this way any mail that comes in while the new IP address is propagating,
will be received and forwarded to the new server
> * Change DNS record for mail2.example.com to point to the new server's
> IP address.
remember to reset the TTL on the record
Kevin Bailey
This is getting more complicated and maybe is a question RE DNS.
Can I point MX records at a server on a different domain - i.e. can the
MX record for example1.com point to mail2.example2.com?
Probably not!
Does anyone have any suggestion on how to be able to move email hosting
for about 20 domains in one switch?
I was hoping to tidy up all domains and get all MX records pointing to
mail2.mydomain.com - then I could change a single A record
(mail2.mydomain.com) which would redirect all traffic to another newer
server.
Cheers,
Kevin
Erwan David
> Kevin Bailey wrote:
> >I need to move the hosting of email of several domains from one server
> >to another. This second email server will have a different IP address
> >- due to the server farm being different I can not use the existing
> >server's IP address.
> >
> >Say all mail is being directed to an address such as mail2.example.com.
> >
> >Is all I have to do is:
> as somebody else noted: set the TTL on the current record very low - do
> this well in advance of the cutover
With well in advance = more than the current TTL in advance.
--
Erwan
Erwan David
>
> This is getting more complicated and maybe is a question RE DNS.
>
> Can I point MX records at a server on a different domain - i.e. can the
> MX record for example1.com point to mail2.example2.com?
>
> Probably not!
Yes it can. Look at the MXs for rail.eu.org, one of them is in another
domain.
--
Erwan
Jorey Bump
> * Wait and as the new IP address is distributed the mail will start
> arriving at the new server.
Others have pointed out the critical step of lowering your TTL (I use 5
minutes for this kind of operation) and waiting until your current TTL
has expired before you proceed. I also find it useful to run a report
afterwards on a site like dnsstuff.com, to reveal anything I might have
overlooked.
If there is any way at all that you can keep the current IP address, I
highly recommend it, even as an alias. I moved my servers to a
completely new network last year, and was astonished to find major ISPs
caching DNS well beyond the TTLs I had set. I continue to have a problem
with Comcast, which appears to have a broken resolver available to its
mail servers. Most of the time, Comcast mail gets through, but, like a
game of russian roulette, it will hit the bad resolver and return the
message with "User unknown" in the subject(!) and "550 [PERMFAIL]
destination not valid within DNS" as the error (I have a comcast.net
account and comfirmed this). My guess is that the bad resolver is stuck
in time, and has an ancient cache that doesn't include recent changes,
otherwise a huge chunk of mail relayed via Comcast wouldn't get
delivered (for all I know, this is true, but I just can't accept that
possibility).
Joris
>Kevin Bailey wrote:
>
>>* Wait and as the new IP address is distributed the mail will start
>>arriving at the new server.
>
>Others have pointed out the critical step of lowering your TTL (I
>use 5 minutes for this kind of operation) and waiting
Be aware that setting TTLs to such a short period triggers many ISPs
to default to a much longer time to reduce the load on their DNS.
joris
Rod Dorman
>> ...
> * Drop the TTL of the domain so you don't have to wait so long for the rest of
> the Internet to catch up.
Note that you only should "Drop the TTL" on the record(s) you are going
to be changing.
The others (e.g. 'A' records for FTP servers) don't need to be touched.
--
ro...@polylogics.com "The avalanche has already started, it is too
Rod Dorman late for the pebbles to vote." - Ambassador Kosh
Bryan Irvine
> On Montag, 5. März 2007 18:57 Joris wrote:
> > >Others have pointed out the critical step of lowering your TTL (I
> > >use 5 minutes for this kind of operation) and waiting
> >
> > Be aware that setting TTLs to such a short period triggers many ISPs
> > to default to a much longer time to reduce the load on their DNS.
>
personally, I usually use an hour.
--Bryan