Re: Sending Non Delivery Reports? (was Pump and Dump)

John E. Malmberg wrote:
> Garen Erdoisa wrote:
>>
>> Well I can only speak for myself, but I have been using SPF now for 
>> over a year and have yet to see a case where rejecting an email that 
>> failed an SPF check caused any problems. For me at least it solved far 
>> more problems that it might potentially have caused.
> 
> If the postmaster where I pick up my e-mail from implements SPF to 
> reject alleged forwarding, I would lose a significant portion of my e-mail.

This can indeed happen if the postmaster does not follow the 
recommendations put forth on how to resolve issues like this for 
forwarding email servers as part of his implementation. That is not the 
fault of SPF, that is an administration issue for that one site and 
situation. The recommended solution for those who wish to implement SPF 
is to re-write the envelope sender address as part of the forwarding 
process so the forwarded mail isn't rejected due to an SPF failure. This 
is a trivial task that can be done with a handful of lines of procmail 
code and a cronjob. It isn't rocket science.

> 
> One of my public e-mail addresses is a forwarding service, and SPF 
> specifically breaks such forwarding services because they all they add 
> is a header line, and do not rewrite the other parts of the header.

That is not the fault of the SPF protocol. If they are not following the 
recommendations even that much, that is just being lazy.

> 
> The "solution" described by the SPF is to require replacement of the 
> software in use by the mail forwarding service.

That is one possible scenario yes. There are other means to accomplish 
the same task without having to replace much in the way of existing 
software.

> 
> I have seen posted several times on the DSBL and other mailing list 
> archives that the RFCs require all systems connected to the public 
> internet to have a working rDNS.

I've heard that also, but I have yet to find the relevant RFC's. 
Admittedly I have not looked that hard for that particular one since it 
is of no concern to me. All my hosts have correct working rDNS and have 
since the day they went online, so it's not really a piece of 
information I've been all that motivated to find. :-)

> 
> Considering that a strict rDNS check foils more spam attempts than SPF 
> does, and can not be implemented because there are a few popular 
> networks that can not take the 15 minutes to correct their rDNS, an 

Strict rDNS checks can also foil legitimate email. China is a good 
example. They use their own root name servers so it's rare that you'll 
find an IP hailing from China that has an rDNS mapped to anything on our 
name servers other than for required ISP roll accounts. I receive a lot 
of spam attempts from China. I block all of China also, because I don't 
know anyone there, and have no desire to establish any business 
relationships with anyone there. However that does not mean that there 
is never any good mail out of China. I'm sure there is quite a lot, 
hopefully more good mail than spam. If it weren't for the continual spam 
attempts from that geographical area, I would remove the block.

> anti-spam system that requires a modification or replacement to RFC 
> compliant mail processing systems owned by others is not a good solution.

I have a problem with your logic here, see below.

> 
> If you run a small domain where you personally know all the users and 
> where they get their e-mail from, you can safely implement SPF to reject 
> spam/backscatter.

Yes. You an also do the same for a large ISP, or MSP, or mail forwarding 
service, or list mail servers, etc. The issues that have been raised are 
not insurmountable. IMO, it's a relatively trivial administration task. 
Once it's setup and working properly it requires little maintenance.

> 
> For the large domains that are proposing/promoting it, they do not seem 
> to care how many of their users that they are breaking e-mail reception 
> for.

I doubt that. I think that businesses do care very much what their 
clients think and believe and go to great lengths to make their clients 
happy. Especially so when they find out their clients are unhappy with 
some aspect of their business relationship.

The old business motto comes to mind. Happy customers are repeat 
customers, and repeat customers are what keeps a business alive.

People who choose to implement SPF do so for a reason. It's not 
something they do willy nilly for no reason at all.

I certainly would not have done so myself if I didn't have a damn good 
reason. That reason was that I absolutely needed a way to discourage 
spammers from forging my domain into the from headers of their spams. My 
site was under such abusive attacks and harassment for several months 
over a year ago before I stumbled on SPF as a possible solution. I knew 
it was a draft then, but chose to implement it early out of necessity. 
It did solve that particular problem for my case.

> 
> Now as far as your backscatter problem:
> 
> Can you modify your DNS server to respond differently to the I.P. 
> addresses of the few mail servers generating the backscatter?
> 
> If so, present them with an MX record resolving to 127.0.0.1, it will 
> eventually eliminate the backscatter from those servers.

Yes I am quite capable of modifying source code of software to change 
it's functionality. However I have 2 problems with this approach.

1) You stated above that in your opinion you thought that it was not to 
your liking that SPF would require software updates of software owned by 
others in order to implement the RFC properly for forwarders.

Now here you are recommending that I hack my own DNS servers in order to 
trick the sending servers into sending the DSN notices to their own 
localhost postmaster accounts. This tantamount to fighting abuse with 
abuse, and is at the same time recommending that I (and possibly others) 
modify software to solve a spam problem.

It doesn't really look all that good when you state in one paragraph 
that you are against the SPF requirement that software be modified to 
fully implement their solution, then turn right around and suggest that 
I modify my software to implement your alternate solution, without even 
an RFC draft in hand?

Also I do believe that your suggestion (while admittedly funny in 
practice) *would* violate the RFC's relevant to good DNS management. It 
would violate net etiquette in the sense that you would have me have my 
DNS servers actually lie about the addresses assigned to my MX. It would 
violate my own sense of ethics as well, and it would not necessarily 
solve the problem. I think that it would at most just hide it from view.

2) Such modification of DNS software if this became a general practice 
could also be used to abuse other servers. You don't have to set the 
record to 127.0.0.1, in theory it could be set to *any* IP address. This 
would also be tantamount to net abuse in it's own right. I have never 
seen or heard of any such project being seriously proposed for use on 
the Internet to fight spam.

In any case, the Internet is a constantly changing community of 
cooperating networks. One of the problems with spam is that senders 
forge addresses. SPF is one of several solutions proposed to deal with 
that. SPF is not and never was intended to be the solution to end spam. 
It is only supposed to help deal with MAIL FROM: forgery and HELO 
forgery. If it's used properly, I think that it does it's job quite well.

Thank you for sharing your thoughts. :-)
Be well

 >[snip]

--
Garen