[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

RE: SPF was Re: never use sorbs




> -----Original Message-----
> From: Michael Loftis [mailto:mloftis@modwest.com]
> --On July 28, 2006 4:08:24 AM +0100 James Stevenson <james@stev.org>
> >> -----Original Message-----
> >> From: Stephen Gran [mailto:sgran@debian.org]
> >> Sent: 28 July 2006 01:10
> >> This one time, at band camp, Paul Johnson said:
> >> > On Thursday 27 July 2006 09:23, Michael Loftis wrote:
> >> >
> >> > > forwarders also don't work
> >> >
> >> > They do if you implement SRS like you're supposed to if you're
> running
> >> > a forwarder.
> >>
> >> Is there a functional SRS out there?  I had thought it was pretty much
> a
> >> dead end, since you can either decide not to forward DSN's back to the
> >> original sender, or risk being an open relay.  Both of those count as
> >> non-functional options in my book.
> >
> > I really fail to see the problem with the forwards. Surly a host can be
> > configured to turn a blind eye to backup mail servers and the likes.
> Since
> > the backup should verify the SPF records. What's the requirement for the
> > SRS forwarder ? Or if a lot of mail is coming from a forwarders why
> > should it not be added to the SPF record ?
> 
> That's just it, if you're forwarding for a customer, then you'd be
> forwarding the envelope right now with a MAIL FROM of say @stev.org, so if
> you were mailing one of our customers, and they asked us to forward mail
> to
> a server who implemented SPF, and you had an SPF record, *YOU* would have
> to figure out an publish *OUR* MXers.  Because *WE* would *APPEAR* to be
> sending the mail to the third server that our customer has asked us to
> forward their mail to.  That server may or may not (often not) be under
> their control even.
> 
> SPF to me is just more broken than fixed.  We do enough forwarding for
> customer addresses that we can't deploy it without seriously breaking all
> mail we send and claiming envelope senders of our machines, then you never
> really know who to send the bounce to, and it also opens up the nasty
> potential to be abused when that bounce return leaks and spambots start to
> try to hit it.

I understand the above ok. But what the problem with the server that handles
the initial MX records doing the spf filtering and the end server configured
in such a way that it understand not todo SPF filter from that forwarding
server after all its running you mail which in my words your already
"trusting" it. IT does increase the configuration overheads slightly.

I guess the same also exists for multiple MX sites when the backup server
send mail to the primary MX server.





Reply to: