Re: Welcome to the new(ish) ASRG list

haha so am I a member of the fussp brigade?

Sadly anything IP based is never going to work. I firmly believe the fix 
will have to be transport and law agnostic.
Changing the transport system is just too hard and with all hard things they 
become very brittle.


Regards
Chris

On 17/03/2013 1:47 PM, Rob McEwen wrote:
> On 3/16/2013 7:53 PM, Chris wrote:
>> essentially its a reputation system. To send an email you need to
>> attach a stamp. if that stamp is successfully received it gives the
>> sender a new stamp so he can send another email.
> It seems to me that if the industry would do the following:
>
> (1) get strongly behind *requiring* FCrDNS for IPs sending
> NON-authenticated mail (i.e. "last external" MTA)
>
> (2) and ESPECIALLY make that a *requirement* for NON-authenticated IPv6
> e-mail
>
> (3) Then solve the HUGE HUGE HUGE HUGE and CONSTANTLY UNDER-RATED
> problem of overabundance of mail-sending IPv6 addresses (a spammer's
> dream as they never run out of new fresh IPs, and can send each e-mail
> from a DIFFERENT IP address!) ...we could solve that problem... by
> simply making it an industry standard to block ALL NON-authenticated
> IPv6 mail that doesn't originate from one single designated (as in
> "standardized") "root" IP per /48 block. (or, make it even MORE
> scarce... like one designated IP per /36 block? other?)... this would be
> the equivalent of blocking all NON-authenticated IPv4 mail that isn't
> sent from an IP ending in ".0"... sort of like that, except far more
> strict. IPv6 mail-sending is still youthful enough to where it isn't too
> late to get behind this idea... but time is running out!
>
> ...those won't be a magic cure... would go a long way towards helping to
> solve the spam problem... and these suggestions ARE feasible because
> they (A) use existing technologies, and (B) in the case of FCrDN,
> involve already existing "best practices".
>
> NOTE: I specified "NON-authenticated mail" because I'm making the point
> that ANY ip address can still password-authenticate to an MTA for that
> MTA to then send the message on their behalf. These ideas don't impact
> THAT part at all... so your toaster or watch or car or whatever can
> STILL send an e-mail to you via smtp-authentication via ANY IP (as long
> as it uses a valid SMTP mail server and doesn't try to send directly,
> like a botnet would do.)
>