Marc: use SPF to prevent backscatter? Was RE: [AMaViS-user] Q about mail proxy servers and setups

[Michael Scheidell <sc...@secnap.net>]

One thing I would like to see (and this is a different subject:
Marc: take note:  Id like to NOT BOUNCE an email back to the victim of
backscatter if they bothered to publish SPF or SENDER ID records that
don't match the incoming.

(and, yes, this would NOT work behind a proxy)

I would like the proxy to at LEAST have a copy of the valid userlist,
NOT muck with the headers.
MAYBE do its load balancing via bridging rather than store forward.
That might fix a lot. But then again, it would be easier to replace the
proxy than fix it.
-- 
Michael Scheidell, CTO
Office: 561-999-5000 x 1259
Direct: 561-939-7259
Real time security alerts: http://www.secnap.com/news
_________________________________________________________________________
This email has been scanned and certified safe by SpammerTrap(tm). 
For Information please see http://www.spammertrap.com
_________________________________________________________________________

Re: [AMaViS-user] Marc: use SPF to prevent backscatter? Was RE: Q about mail proxy servers and setups

[Jo Rhett <jr...@netconsonance.com>]

Marc, you shouldn't be bouncing e-mails back at all.  Use D_REJECT  
and make sure you're doing it at the SMTP layer.  SPF or DKIM is  
irrelevant in this situation.

On Sep 23, 2007, at 5:31 PM, Michael Scheidell wrote:
> One thing I would like to see (and this is a different subject:
> Marc: take note:  Id like to NOT BOUNCE an email back to the victim of
> backscatter if they bothered to publish SPF or SENDER ID records that
> don't match the incoming.
>
> (and, yes, this would NOT work behind a proxy)
>
> I would like the proxy to at LEAST have a copy of the valid userlist,
> NOT muck with the headers.
> MAYBE do its load balancing via bridging rather than store forward.
> That might fix a lot. But then again, it would be easier to replace  
> the
> proxy than fix it.
> -- 
> Michael Scheidell, CTO
> Office: 561-999-5000 x 1259
> Direct: 561-939-7259
> Real time security alerts: http://www.secnap.com/news
> ______________________________________________________________________ 
> ___
> This email has been scanned and certified safe by SpammerTrap(tm).
> For Information please see http://www.spammertrap.com
> ______________________________________________________________________ 
> ___
>
> ---------------------------------------------------------------------- 
> ---
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> AMaViS-user mailing list
> AMaViS-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/amavis-user
> AMaViS-FAQ:http://www.amavis.org/amavis-faq.php3
> AMaViS-HowTos:http://www.amavis.org/howto/

-- 
Jo Rhett
Net Consonance : consonant endings by net philanthropy, open source  
and other randomness

Re: Marc: use SPF to prevent backscatter? Was RE: [AMaViS-user] Q about mail proxy servers and setups

[mouss <mo...@netoyen.net>]

Michael Scheidell wrote:
> One thing I would like to see (and this is a different subject:
> Marc: take note:  Id like to NOT BOUNCE an email back to the victim of
> backscatter if they bothered to publish SPF or SENDER ID records that
> don't match the incoming.
>   

It's the other way around. you should only bounce if you can be sure the 
sender was not forged. So, if there is no SPF record, or if the SPD 
record allows the whole universe (or a significant part of it:), then 
you must not bounce.

anyway, SPF penetration is too low to change anything to the problem 
here. same for DKIM for now.
> (and, yes, this would NOT work behind a proxy)
>
> I would like the proxy to at LEAST have a copy of the valid userlist,
>   

This would be a good start.
> NOT muck with the headers.
> MAYBE do its load balancing via bridging rather than store forward.
>   

this is not easy to do:
- most IP stacks do not allow you to bind to an external IP. so you 
would need adding dynamic NAT routes (and even this is not that simple, 
because you need different NAT rules for different connections, so you 
the proxy needs to bind to a port before adding the NAT rule and before 
doing a connect()).
- in any case, the proxy needs to be modified (in a modified stack, it 
would just bind to the client IP. in a standard stack, it should do the 
above).
- the final server must route back packets through the proxy machine, 
probably with a default route. but then you must ensure no host that is 
not routed this way will not connect to the proxy (there's no 
"conference" in TCP).
- any intermediary routers/gateways/... should keep this traffic going 
between the proxy and the final server.

it would certainly be easier to modify the proxy to fix the real problem 
than try to convert it into a "bridging proxy" (I don't like 
"transparent proxy" term: there are many levels of transparency).

> That might fix a lot. But then again, it would be easier to replace the
> proxy than fix it.
>   

yes. fixing problems introduced by legacy applications is often harder 
than solving the real problems (and getting rid of the legacy apps)... 
Unfortunately, there's much "feeling" and "confidence" issues when 
trying to convince the customer to take another road (and sometimes, the 
customer representative will resist the change because he did not 
suggest it, or because he can no more justify a lost budget).

Re: Marc: use SPF to prevent backscatter? Was RE: [AMaViS-user] Q about mail proxy servers and setups

[Clifton Royston <cl...@lava.net>]

On Sun, Sep 23, 2007 at 08:31:04PM -0400, Michael Scheidell wrote:
> One thing I would like to see (and this is a different subject:
> Marc: take note:  Id like to NOT BOUNCE an email back to the victim of
> backscatter if they bothered to publish SPF or SENDER ID records that
> don't match the incoming.
> 
> (and, yes, this would NOT work behind a proxy)
 
  As I said, it *could* if the proxy in question at least puts in a
proper received header, and you can fish the info out of there.  (If it
doesn't, I believe it's in serious violation of RFC 821/2821 and
822/2822; a mailserver MUST insert a Received header for itself.)

> I would like the proxy to at LEAST have a copy of the valid userlist,
> NOT muck with the headers.

  Do I understand from this that 1) it's store-and-forward, not
transparently proxying, and 2) it doesn't currently validate the
recipients before accepting the mail?  If so, that's a pretty strong
argument for either replacing or fixing it.  Validating recipients at
the edge has been BCP for email for many years now.

  Once the mail is accepted into the network, I think the onus is on
you collectively to either deliver or drop it, not bounce - not in the
current email regime.  Not only does bouncing cause misery to others
whose addresses have been forged, not only does it make your company a
backscatter spam source - which could get you on DNSBLs - it also means
that you're doubtless wasting resources on having to accept and then
generate bounces for an absurd amount of mail for users who don't exist
except in the minds of some spambot.

  If whoever's responsible for the proxy is not able to implement
normal recipient validation, I think this makes a good case that they
aren't able to keep it running adequately.

  I realize I'm preaching to the choir, but perhaps this offers some
ammunition you can use to make your case.

> MAYBE do its load balancing via bridging rather than store forward.

  If you can instead reengineer it to *shed* some of the existing load,
by introducing more up-to-date antispam measures, that might be better
than just balancing the load.

> That might fix a lot. But then again, it would be easier to replace the
> proxy than fix it.

  It is starting to sound like it.  But if you can do neither, I think
you're better off trying to never bounce any spam - configure the MTA
under your control to discard all undeliverable messages.

  If company policy forbids that and says you *must* bounce mail to
undeliverable addresses, perhaps you can at least get it agreed to
bounce only *after* running the incoming stream through a spam/virus
filter set to discard, so that you would generate NDNs only for mail
which does not appear to be spam or a virus.  This is the opposite of
what would normally be considered the desirable sequence, but if the
proxy is accepting the mail in the first place, and that's out of your
hands, you can at least reduce the volume of spurious bounces.

  All IMHO, naturally
  -- Clifton

-- 
    Clifton Royston  --  cliftonr@iandicomputing.com / cliftonr@lava.net
       President  - I and I Computing * http://www.iandicomputing.com/
 Custom programming, network design, systems and network consulting services