[gentoo-user] {OT} reverse DNS problem?

[gentoo-user] {OT} reverse DNS problem?

[Grant]

When I try to send an email to a ucla.edu email address from my hosted
server, the message bounces and I'm directed to this page:

http://info.smtp.ucla.edu/faq.php

which says:

"The gateway disallows direct connections from residential broadband
systems, from other dynamically allocated IP addresses, or from hosts
with "generic" reverse DNS entries (ie, a variation of A-B-C-D.isp.com
for D.C.B.A)."

I do get this:

$ ping -c 1 mydomain.com
PING mydomain.com (m.y.i.p) 56(84) bytes of data.
64 bytes from p.i.y.m.static.reverse.myhost.com (m.y.i.p): icmp_seq=1
ttl=49 time=1267 ms

Does anyone know how to fix this?

- Grant

Re: [gentoo-user] {OT} reverse DNS problem?

[Stroller]

Relay through your ISP.

Using Postfix this is /etc/transports (and `postmap /etc/postfix/ 
transport` and restart Postfix)

If you have any influence at ucla.edu tell them how much their policy  
sucks.

Stroller.


On 3 Sep 2009, at 21:45, Grant wrote:

> When I try to send an email to a ucla.edu email address from my hosted
> server, the message bounces and I'm directed to this page:
>
> http://info.smtp.ucla.edu/faq.php
>
> which says:
>
> "The gateway disallows direct connections from residential broadband
> systems, from other dynamically allocated IP addresses, or from hosts
> with "generic" reverse DNS entries (ie, a variation of A-B-C-D.isp.com
> for D.C.B.A)."
>
> I do get this:
>
> $ ping -c 1 mydomain.com
> PING mydomain.com (m.y.i.p) 56(84) bytes of data.
> 64 bytes from p.i.y.m.static.reverse.myhost.com (m.y.i.p): icmp_seq=1
> ttl=49 time=1267 ms
>
> Does anyone know how to fix this?
>
> - Grant
>

Re: [gentoo-user] {OT} reverse DNS problem?

[Paul Hartman]

On Thu, Sep 3, 2009 at 3:45 PM, Grant<emailgrant@gmail.com> wrote:
> When I try to send an email to a ucla.edu email address from my hosted
> server, the message bounces and I'm directed to this page:
>
> http://info.smtp.ucla.edu/faq.php
>
> which says:
>
> "The gateway disallows direct connections from residential broadband
> systems, from other dynamically allocated IP addresses, or from hosts
> with "generic" reverse DNS entries (ie, a variation of A-B-C-D.isp.com
> for D.C.B.A)."
>
> I do get this:
>
> $ ping -c 1 mydomain.com
> PING mydomain.com (m.y.i.p) 56(84) bytes of data.
> 64 bytes from p.i.y.m.static.reverse.myhost.com (m.y.i.p): icmp_seq=1
> ttl=49 time=1267 ms
>
> Does anyone know how to fix this?

Have the company from whom you get your static IP set up the reverse
DNS to be your domain rather than the generic myhost.com address.

Re: [gentoo-user] {OT} reverse DNS problem?

[Stroller]

Ooops... please ignore.  I just noticed you said "from my hosted  
server".

You can still try complaining to them. Good luck!!

Stroller.




On 3 Sep 2009, at 21:51, Stroller wrote:

> Relay through your ISP.
>
> Using Postfix this is /etc/transports (and `postmap /etc/postfix/ 
> transport` and restart Postfix)
>
> If you have any influence at ucla.edu tell them how much their  
> policy sucks.
>
> Stroller.
>
>
> On 3 Sep 2009, at 21:45, Grant wrote:
>
>> When I try to send an email to a ucla.edu email address from my  
>> hosted
>> server, the message bounces and I'm directed to this page:
>>
>> http://info.smtp.ucla.edu/faq.php
>>
>> which says:
>>
>> "The gateway disallows direct connections from residential broadband
>> systems, from other dynamically allocated IP addresses, or from hosts
>> with "generic" reverse DNS entries (ie, a variation of A-B-C- 
>> D.isp.com
>> for D.C.B.A)."
>>
>> I do get this:
>>
>> $ ping -c 1 mydomain.com
>> PING mydomain.com (m.y.i.p) 56(84) bytes of data.
>> 64 bytes from p.i.y.m.static.reverse.myhost.com (m.y.i.p): icmp_seq=1
>> ttl=49 time=1267 ms
>>
>> Does anyone know how to fix this?
>>
>> - Grant
>>
>

Re: [gentoo-user] {OT} reverse DNS problem?

[Alan McKinnon]

On Thursday 03 September 2009 22:51:04 Stroller wrote:
> Relay through your ISP.
> 
> Using Postfix this is /etc/transports (and `postmap /etc/postfix/
> transport` and restart Postfix)
> 
> If you have any influence at ucla.edu tell them how much their policy
> sucks.

ucla.edu have the perfect policy.

I refuse point blank to accept any mail whatsoever from dynamic ranges or 
insane reverse lookups.

Why? Because doing so immediately gets rid of 1,000,000+ spam messages PER 
DAY.

Yes, you read that right - a million spams each and every day. The number of 
users with other ISPs that have valid reasons to host MTAs on DSL is tiny in 
comparison and they can relay through their ISP (or get a different one that 
understands mail). Do you have any idea how much that bandwidth costs in a 
third world country? Or the spam cluster to deal with it?

Management agree with that sentiment. Although they did raise an eyebrow a 
year ago when a colleague blocked ALL of China. They asked him nicely to 
narrow things down a bit to actual offenders :-)


-- 
alan dot mckinnon at gmail dot com

Re: [gentoo-user] {OT} reverse DNS problem?

[Mike Kazantsev]

[-- Attachment #1: Type: text/plain, Size: 716 bytes --]

On Thu, 3 Sep 2009 13:45:46 -0700
Grant <emailgrant@gmail.com> wrote:

> When I try to send an email to a ucla.edu email address from my hosted
> server, the message bounces and I'm directed to this page:
> 
...
> 
> Does anyone know how to fix this?

If you have an open mail relay server, you can use that, as already
suggested. Strange thing, but I've never seen one ;)

My solution is to use SASL authentication with any SMTP, so you can
relay your message through any server, like gmail.com, for example.
All you need is to find sendmail substitute that supports it, and if
you don't need a full-fledged MTA to receive mail, I'd suggest to try
out msmtp.

-- 
Mike Kazantsev // fraggod.net

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] {OT} reverse DNS problem?

[Stroller]

On 3 Sep 2009, at 22:14, Alan McKinnon wrote:
> On Thursday 03 September 2009 22:51:04 Stroller wrote:
>> Relay through your ISP.
>>
>> Using Postfix this is /etc/transports (and `postmap /etc/postfix/
>> transport` and restart Postfix)
>>
>> If you have any influence at ucla.edu tell them how much their policy
>> sucks.
>
> ucla.edu have the perfect policy.

They have a poor policy, which drops legitimate mail in favour of an  
easy life for the system administrators.

> I refuse point blank to accept any mail whatsoever from dynamic  
> ranges or
> insane reverse lookups.
>
> Why? Because doing so immediately gets rid of 1,000,000+ spam  
> messages PER
> DAY.

Have you previously checked IPs against Spamhaus (85% of spam caught)  
and also that the HELO address resolves correctly?

IE: mail from IP address 1.2.3.4 - which reverse lookups to  
dsl-1-2-3-4.some.isp.net - is currently rejected, but the policy could  
be changed to allow it if the mailserver connects saying HELO  
coolname.com AND coolname.com resolves to 1.2.3.4

A spammer installing a virus on home PCs cannot afford to buy a domain  
name for each of them, and if he allocates a sub-domain to each  
infected computer then you can simply block the whole domain. I  
believe you can check domains which are more or less than 14 days old  
to allow for registrars offering no-payment grace periods.

> ... Do you have any idea how much that bandwidth costs in a
> third world country? Or the spam cluster to deal with it?

You may be in a slightly exceptional position in that the bandwidth  
cost - of syncing to Spamhaus and the additional DNS lookups - may be  
prohibitive. UCLA are not.

Whatever the proportion of legitimate mail this policy rejects, this  
policy DOES reject legitimate mail, and that's pretty lame because  
there are other ways to achieve the goal (reduction of spam) without  
that side-effect.

If you read postfix-users then you'll find many mail administrators in  
a similar position to your own (dealing with millions of messages  
daily) on that list, and that simply blocking home DSL connections is  
not very popular amongst them. It's not considered a cool policy  
because it's inefficient. I am not an expert on this subject - I'm  
pretty sure there are other methods which will identify legitimate  
hosts versus spammers which should be implemented before this one, but  
I do not know the details.

Stroller.

Re: [gentoo-user] {OT} reverse DNS problem?

[Alan McKinnon]

On Friday 04 September 2009 17:23:15 Stroller wrote:
> You may be in a slightly exceptional position in that the bandwidth  
> cost - of syncing to Spamhaus and the additional DNS lookups - may be  
> prohibitive. UCLA are not.
> 
> Whatever the proportion of legitimate mail this policy rejects, this  
> policy DOES reject legitimate mail, and that's pretty lame because  
> there are other ways to achieve the goal (reduction of spam) without  
> that side-effect.
> 
> If you read postfix-users then you'll find many mail administrators in  
> a similar position to your own (dealing with millions of messages  
> daily) on that list, and that simply blocking home DSL connections is  
> not very popular amongst them. It's not considered a cool policy  
> because it's inefficient. I am not an expert on this subject - I'm  
> pretty sure there are other methods which will identify legitimate  
> hosts versus spammers which should be implemented before this one, but  
> I do not know the details.

Every other solution out there has this one little problem that people seem to 
ignore.

Per RFC, if you accept the connection and the mail, you will deliver it. 
That's what it says. It also says this since days long before spam problems, 
but still. We all conveniently ignore this if we are talking about what *we* 
consider spam, and by "we" I mean "everyone who cares to take an interest 
except the actual recipient".

Yes, that's what it reduces down to. The recipient cannot by definition be 
part of the anti-spam process as the mail is discarded before he/she can see 
it. Yet we accepted the mail implying that we will deliver it...

Best policy is to stipulate in the ISP's terms of service that you will not 
accept inbound mail connections from range you feel you cannot trust and users 
must use their ISPs mail relay instead. Instantly, 85% of the problem goes 
away, and I have numbers to prove it. Plus, it's very hard to police 
individual users out there, but if they use the ISP's relay instead I have a 
single point of contact. They will then police their own users (otherwise I 
cut their mail link), just like I police my own outbound users.

And why is a user on a DSL range running a mail server anyway? The vast 
overwhelming majority of them are Windows zombies!

And finally, my mail servers are mine and I make decisions about them, not 
someone else.

-- 
alan dot mckinnon at gmail dot com

Re: [gentoo-user] {OT} reverse DNS problem?

[Stroller]

On 4 Sep 2009, at 21:49, Alan McKinnon wrote:
> On Friday 04 September 2009 17:23:15 Stroller wrote:
> ...
> Every other solution out there has this one little problem that  
> people seem to
> ignore.
>
> Per RFC, if you accept the connection and the mail, you will deliver  
> it.
> That's what it says. It also says this since days long before spam  
> problems,
> but still. We all conveniently ignore this if we are talking about  
> what *we*
> consider spam, and by "we" I mean "everyone who cares to take an  
> interest
> except the actual recipient".
>
> ... Yet we accepted the mail implying that we will deliver it...

I don't think it's necessary to break RFC if you reject based on a  
bogus HELO. The connection is initiated, but you do not get as far as  
accepting the mail.

> Instantly, 85% of the problem goes
> away, and I have numbers to prove it.

85% of the problem goes away if you use Spamhaus, and that doesn't  
require you to discard legitimate email.

> And why is a user on a DSL range running a mail server anyway?

Personally, from my own point of view, it's so that I can see clearly  
that a message has been delivered.

EG:

Sep  1 18:42:22 compaq postfix/smtp[6121]: A66A2137D25: to=<XXX@yahoo.co.uk 
 >, relay=mx1.mail.eu.yahoo.com[217.12.11.64], delay=2, status=sent  
(250 ok dirdel)

I get complaints ALL the time from my customers, "oh, my brother /  
mother / customer / supplier says they sent me an email and I never  
received it". The only way I can debug this is to send them test  
messages (sometimes daily) and tell them to let me know if they don't  
arrive.

If a customer comes to you with a log entry that looks like the above,  
referring to your server's hostname & IP, complaining the message was  
never delivered, then you can, reluctantly, look in the problem,  
grepping for A66A2137D25.

If the customer comes to you with a log entry like the above with  
relay=smtp.my-isp.com then your response will be "oh, we probably  
never got the message from your ISP". I presumably can log a support  
issue with my ISP & expect them to come up with the log of the message  
being delivered to your servers, but it's simply easier if I can debug  
non-deliveries myself.

> The vast
> overwhelming majority of them are Windows zombies!

Which are easily filtered by checking their HELO resolves to an  
independent domain. Or am I missing something here?

The remainder of those you're inefficiently filtering are Linux  
enthusiasts running Postfix on their Gentoo boxes.

> And finally, my mail servers are mine and I make decisions about  
> them, not
> someone else.

Sure, but you're making unilateral decisions about the validity of  
emails on behalf of your customers. And around here the customer comes  
first.

If Bob wants to send Alice an email, he shouldn't have to reconfigure  
his email server because Fred, the systems administrator at Alice's  
ISP, is being a knob about things.

You may be the exception, having a narrow pipe and being unable to  
afford the Spamhaus / DNS lookups to filter spambots in efficient  
ways. Most systems administrators using this policy are unable to  
justify the decision.

> Best policy is to stipulate in the ISP's terms of service that you  
> will not
> accept inbound mail connections from range you feel you cannot trust  
> and users
> must use their ISPs mail relay instead.

You certainly won't get me subscribing to your service.

Stroller.

Re: [gentoo-user] {OT} reverse DNS problem?

[Grant]

>> Every other solution out there has this one little problem that people
>> seem to
>> ignore.
>>
>> Per RFC, if you accept the connection and the mail, you will deliver it.
>> That's what it says. It also says this since days long before spam
>> problems,
>> but still. We all conveniently ignore this if we are talking about what
>> *we*
>> consider spam, and by "we" I mean "everyone who cares to take an interest
>> except the actual recipient".
>>
>> ... Yet we accepted the mail implying that we will deliver it...
>
> I don't think it's necessary to break RFC if you reject based on a bogus
> HELO. The connection is initiated, but you do not get as far as accepting
> the mail.
>
>> Instantly, 85% of the problem goes
>> away, and I have numbers to prove it.
>
> 85% of the problem goes away if you use Spamhaus, and that doesn't require
> you to discard legitimate email.
>
>> And why is a user on a DSL range running a mail server anyway?
>
> Personally, from my own point of view, it's so that I can see clearly that a
> message has been delivered.
>
> EG:
>
> Sep  1 18:42:22 compaq postfix/smtp[6121]: A66A2137D25:
> to=<XXX@yahoo.co.uk>, relay=mx1.mail.eu.yahoo.com[217.12.11.64], delay=2,
> status=sent (250 ok dirdel)
>
> I get complaints ALL the time from my customers, "oh, my brother / mother /
> customer / supplier says they sent me an email and I never received it". The
> only way I can debug this is to send them test messages (sometimes daily)
> and tell them to let me know if they don't arrive.
>
> If a customer comes to you with a log entry that looks like the above,
> referring to your server's hostname & IP, complaining the message was never
> delivered, then you can, reluctantly, look in the problem, grepping for
> A66A2137D25.
>
> If the customer comes to you with a log entry like the above with
> relay=smtp.my-isp.com then your response will be "oh, we probably never got
> the message from your ISP". I presumably can log a support issue with my ISP
> & expect them to come up with the log of the message being delivered to your
> servers, but it's simply easier if I can debug non-deliveries myself.
>
>> The vast
>> overwhelming majority of them are Windows zombies!
>
> Which are easily filtered by checking their HELO resolves to an independent
> domain. Or am I missing something here?
>
> The remainder of those you're inefficiently filtering are Linux enthusiasts
> running Postfix on their Gentoo boxes.

Yeah, I was planning on setting up postfix on my home Gentoo box too.
I guess I could relay through my ISP to avoid delivery problems like
this.

Why hasn't greylisting been mentioned?  I greylist and it ends up
blocking at least 99% of spam in my experience.

- Grant


>> And finally, my mail servers are mine and I make decisions about them, not
>> someone else.
>
> Sure, but you're making unilateral decisions about the validity of emails on
> behalf of your customers. And around here the customer comes first.
>
> If Bob wants to send Alice an email, he shouldn't have to reconfigure his
> email server because Fred, the systems administrator at Alice's ISP, is
> being a knob about things.
>
> You may be the exception, having a narrow pipe and being unable to afford
> the Spamhaus / DNS lookups to filter spambots in efficient ways. Most
> systems administrators using this policy are unable to justify the decision.
>
>> Best policy is to stipulate in the ISP's terms of service that you will
>> not
>> accept inbound mail connections from range you feel you cannot trust and
>> users
>> must use their ISPs mail relay instead.
>
> You certainly won't get me subscribing to your service.
>
> Stroller.

Re: [gentoo-user] {OT} reverse DNS problem?

[Grant]

>> When I try to send an email to a ucla.edu email address from my hosted
>> server, the message bounces and I'm directed to this page:
>>
>> http://info.smtp.ucla.edu/faq.php
>>
>> which says:
>>
>> "The gateway disallows direct connections from residential broadband
>> systems, from other dynamically allocated IP addresses, or from hosts
>> with "generic" reverse DNS entries (ie, a variation of A-B-C-D.isp.com
>> for D.C.B.A)."
>>
>> I do get this:
>>
>> $ ping -c 1 mydomain.com
>> PING mydomain.com (m.y.i.p) 56(84) bytes of data.
>> 64 bytes from p.i.y.m.static.reverse.myhost.com (m.y.i.p): icmp_seq=1
>> ttl=49 time=1267 ms
>>
>> Does anyone know how to fix this?
>
> Have the company from whom you get your static IP set up the reverse
> DNS to be your domain rather than the generic myhost.com address.

So if I have multiple websites on the same server, I will have to pick
a domain which will resolve for rDNS for all the domains?

- Grant

Re: [gentoo-user] {OT} reverse DNS problem?

[Stroller]

On 6 Sep 2009, at 00:52, Grant wrote:

>>> When I try to send an email to a ucla.edu email address from my  
>>> hosted
>>> server, the message bounces and I'm directed to this page:
>>>
>>> http://info.smtp.ucla.edu/faq.php
>>>
>>> which says:
>>>
>>> "The gateway disallows direct connections from residential broadband
>>> systems, from other dynamically allocated IP addresses, or from  
>>> hosts
>>> with "generic" reverse DNS entries (ie, a variation of A-B-C- 
>>> D.isp.com
>>> for D.C.B.A)."
>>>
>>> I do get this:
>>>
>>> $ ping -c 1 mydomain.com
>>> PING mydomain.com (m.y.i.p) 56(84) bytes of data.
>>> 64 bytes from p.i.y.m.static.reverse.myhost.com (m.y.i.p):  
>>> icmp_seq=1
>>> ttl=49 time=1267 ms
>>>
>>> Does anyone know how to fix this?
>>
>> Have the company from whom you get your static IP set up the reverse
>> DNS to be your domain rather than the generic myhost.com address.
>
> So if I have multiple websites on the same server, I will have to pick
> a domain which will resolve for rDNS for all the domains?

If you're using Postfix, I think the important thing is that  
myorigin / myhostname will match the rDNS.

That's what applies to the HELO thing, anyway.

I'm not really sure what's supposed to be wrong with your current  
hostname, but if you can get the host to change the rDNS, then they  
can surely change it to something suitable.

Stroller.

Re: [gentoo-user] {OT} reverse DNS problem?

[Stroller]

On 6 Sep 2009, at 00:05, Grant wrote:
>> ...
>> The remainder of those you're inefficiently filtering are Linux  
>> enthusiasts
>> running Postfix on their Gentoo boxes.
>
> Yeah, I was planning on setting up postfix on my home Gentoo box too.
> I guess I could relay through my ISP to avoid delivery problems like
> this.
>
> Why hasn't greylisting been mentioned?  I greylist and it ends up
> blocking at least 99% of spam in my experience.

There are some disadvantages to greylisting mentioned here:

http://en.wikipedia.org/wiki/Greylisting#Disadvantages

I think there may be an issue whereby if greylisting is widely  
implemented & deployed against zombies then the zombies will just be  
written to be RFC-compliant. :(

There's a LOT about this on the Postfix-Users list. It's worth  
subscribing for a week or two - I find it hard to follow, but still  
like I'm learning stuff there (there's quite  a lot of traffic).

Stroller.
  

Re: [gentoo-user] {OT} reverse DNS problem?

[Alan McKinnon]

On Sunday 06 September 2009 02:16:23 Stroller wrote:
> > Why hasn't greylisting been mentioned?  I greylist and it ends up
> > blocking at least 99% of spam in my experience.
> 
> There are some disadvantages to greylisting mentioned here:
> 
> http://en.wikipedia.org/wiki/Greylisting#Disadvantages
> 
> I think there may be an issue whereby if greylisting is widely  
> implemented & deployed against zombies then the zombies will just be  
> written to be RFC-compliant. :(
> 

greylisting currently works quite well. As with all things where you try to 
block someone who'd like to not be blocked, there are trade offs between cost, 
effort and effectiveness. Right now, greylisting still gives a decent bang for 
the buck.

Eventually the zombies will be RFC compliant. Spam authors are somewhat slow 
to catch on but someone will write such a bot and the script kiddy spammers 
will use it. Then we'll counter with something else and the merry go round 
continues.

The basic problem is that SMTP is fundamentally broken and cannot be fixed 
when abused. It is also fundamentally almost perfect and does not need 
tweaking when used <sigh>

These two things are irreconcilable.


-- 
alan dot mckinnon at gmail dot com