Re: A Zero Spam Mail System [Feedback Request]

[bzs]

I don't think there's anything wrong with sounding out some ideas if
they arose from careful thought and sufficient experience and subject
knowledge.

Just saying call us when you've got a unicorn in hand is a brush-off.

But one has to find the right venue for such brainstorming which I
think is the real problem here.

And of course being willing to be shot down and just go back to the
drawing board if one ever really got so far as a "drawing board".

I'll admit this dombox thing has gotten that far even if some were
dissatisfied with the "drawings", clearly a lot of work has gone into
the idea.

But venue might be everything.

A very large list oriented towards operational issues is probably not
the right venue unless one really believes most everyone will see the
brilliance of a solution after reading a short paragraph and perhaps
even want to help or at least become motivated to read further.

And if you don't get that then, well, time for some introspection.

Quite a few of us, myself included, did go and read at least enough of
the long whitepaper to respond with a lot more in specifics than "call
us when you have your unicorn".

-- 
-Barry Shein

Software Tool & Die| b...@theworld.com | http://www.TheWorld.com
Purveyors to the Trade | Voice: +1 617-STD-WRLD   | 800-THE-WRLD
The World: Since 1989  | A Public Information Utility | *oo*

Re: A Zero Spam Mail System [Feedback Request]

[William Herrin]

On Fri, Feb 22, 2019 at 11:42 AM  wrote:
> But when someone says to me spam isn't much of a problem because it's
> mostly blocked by local filtering (i.e., they don't see much spam in
> their inbox), usually in an attempt to shut down any discussion
> entirely, I know I'm hearing from someone who hasn't a clue what
> problems it causes operationally.

Hear hear. 99% of the email reaching my server is spam. That means I
need 100 times the server capacity to process mail than I would need
without spam. 100 times. Two orders of magnitude. I defy anyone to
tell me that's not an operational issue.

Regards,
Bill Herrin


-- 
William Herrin  her...@dirtside.com  b...@herrin.us
Dirtside Systems . Web: 

Re: sendmail.cf

[Stephen Satchell]

On 2/22/19 11:27 AM, b...@theworld.com wrote:
> I don't know the high-water mark for the number of IMPs or more
> specifically how many existed on the NCP->TCP flag day but I'm pretty
> sure the theoretical maximum was 256 tho no doubt someone had a way to
> extend that. But, w/o extensive changes, 256, probably 254, not sure 0
> or 255 could be an IMP number, whatever!

There was no node 0 or 255.  So the number of nodes was capped at 254.
For each node, there were subnodes so that multiple computers at each
location could be addressed.  It wasn't a full 8-bit field.

Re: A Zero Spam Mail System [Feedback Request]

[bzs]

I'm sure some will react to this viscerally but I'd argue that a large
chunk of the spam issue is an operational issue due to factors like:

1. Volume, bandwidth
2. Spammers' address block hijacking and other misuse of resources
3. Revenge (typically DDoS) attacks by spammers
4. General operational, related to #1, but for example how spam
   stresses capex.

No doubt some others.

But when someone says to me spam isn't much of a problem because it's
mostly blocked by local filtering (i.e., they don't see much spam in
their inbox), usually in an attempt to shut down any discussion
entirely, I know I'm hearing from someone who hasn't a clue what
problems it causes operationally.

That's not to argue for opening the floodgates on spam mitigation on
nanog.

Only that it's not necessarily off-topic depending on the aspect
raised.

-- 
-Barry Shein

Software Tool & Die| b...@theworld.com | http://www.TheWorld.com
Purveyors to the Trade | Voice: +1 617-STD-WRLD   | 800-THE-WRLD
The World: Since 1989  | A Public Information Utility | *oo*

Re: sendmail.cf

[bzs]

On February 22, 2019 at 10:50 bj...@mork.no (Bjørn Mork) wrote:
 > b...@theworld.com writes:
 > 
 > > The predecessor to sendmail was delivermail, 1979, also written by
 > > Eric Allman.
 > >
 > >   https://en.wikipedia.org/wiki/Delivermail
 > 
 > Damn.  Now you made me read RFC801 and wonder why we didn't have an
 > updated version for the IPv6 transition.  Or: Where would the Internet
 > have been today without that very explicit "complete switch over" goal?

Not sure what you mean but reasonably late-model sendmail works with
IPv6, it's a compile option which is on by default.

Or do you mean the NCP->TCP transition? The internet was a lot smaller
and one could actually get all the ducks in a line back then.

And almost everyone (if not everyone) was connected via IMPs rather
than CPE routers and the IMPs were more or less centrally managed or
if you managed one you accepted responsibility to work in concert with
the others.

I don't know the high-water mark for the number of IMPs or more
specifically how many existed on the NCP->TCP flag day but I'm pretty
sure the theoretical maximum was 256 tho no doubt someone had a way to
extend that. But, w/o extensive changes, 256, probably 254, not sure 0
or 255 could be an IMP number, whatever!

Largely because your IMP was identified by the last octet of an IP
address (I think that's right) so Boston University was 10.4.0.44
which meant port 4 on IMP 44 (which sat at MIT on the 9th floor of 545
tech square.)

Of course to speak to the net via your IMP connection your computer(s)
also had to switch over to TCP. But, again, these were usually just
one or a few big machines per site likely all in the same room or same
administration group anyhow.

Life was much simpler back then.

-- 
-Barry Shein

Software Tool & Die| b...@theworld.com | http://www.TheWorld.com
Purveyors to the Trade | Voice: +1 617-STD-WRLD   | 800-THE-WRLD
The World: Since 1989  | A Public Information Utility | *oo*

Re: Cogent v6 Blackhole server issues???

[John Von Essen]

Looks like they finally fixed it.. it just sporadically came back up. My 
v4 and v6 transit sessions were never effected. Who knows...



-John

On 2/22/19 1:18 PM, Dennis Burgess via NANOG wrote:

Out of St. Louis, mine has been up since the last reboot of my router.

2001:550:0:1000::421c:802 is my peering..





Dennis Burgess, Mikrotik Certified Trainer
Author of "Learn RouterOS- Second Edition”
Link Technologies, Inc -- Mikrotik & WISP Support Services
Office: 314-735-0270  Website: http://www.linktechs.net
Create Wireless Coverage’s with www.towercoverage.com

-Original Message-
From: NANOG  On Behalf Of John Von Essen
Sent: Friday, February 22, 2019 12:15 PM
To: nanog@nanog.org
Subject: Cogent v6 Blackhole server issues???

2 days ago my IPv6 BGP session to Cogent's Blackhole server went down 
(2001:550:0:1000::421C:802), I've spent all morning emailing their NOC and I'm 
getting nowhere. Anyone else seeing this? Im in the Phila Metro area.

-John

RE: Cogent v6 Blackhole server issues???

[Dennis Burgess via NANOG]

Out of St. Louis, mine has been up since the last reboot of my router.  

2001:550:0:1000::421c:802 is my peering..  





Dennis Burgess, Mikrotik Certified Trainer 
Author of "Learn RouterOS- Second Edition” 
Link Technologies, Inc -- Mikrotik & WISP Support Services 
Office: 314-735-0270  Website: http://www.linktechs.net 
Create Wireless Coverage’s with www.towercoverage.com 

-Original Message-
From: NANOG  On Behalf Of John Von Essen
Sent: Friday, February 22, 2019 12:15 PM
To: nanog@nanog.org
Subject: Cogent v6 Blackhole server issues???

2 days ago my IPv6 BGP session to Cogent's Blackhole server went down 
(2001:550:0:1000::421C:802), I've spent all morning emailing their NOC and I'm 
getting nowhere. Anyone else seeing this? Im in the Phila Metro area.

-John

Cogent v6 Blackhole server issues???

[John Von Essen]

2 days ago my IPv6 BGP session to Cogent's Blackhole server went down 
(2001:550:0:1000::421C:802), I've spent all morning emailing their NOC 
and I'm getting nowhere. Anyone else seeing this? Im in the Phila Metro 
area.


-John

Re: A Zero Spam Mail System [Feedback Request]

[Grant Taylor via NANOG]

On 02/22/2019 09:28 AM, John Curran wrote:
If you (or your email service provider) deploy an optional solution 
(e.g. DMARC p=reject) that prevents you from receiving email from mailing 
lists sending in conformance with existing standards, then that’s 
your choice.


From the perspective of inbound email (as that sounds like the focus of 
your statement) I would want my email server / service to use all 
current standards.  If the current standards are to employ DMARC 
filtering, then I would expect my email server / service provider to do so.


In some ways, I view DMARC as the latest in the line evolving standards; 
DKIM, SPF, reverse DNS.  Each of which have been controversial on their own.


I also believe in actually honoring what domain owners publish.  I 
believe that actually rejecting with SPF's "-all" and DMARC's 
"p=reject".  I say this because I want to provide — hopefully gentle — 
push back against / feedback to the publisher for them to fix their 
problems.


Even if you don't reject despite domain owner's indication of the 
preference, I think you should use that signal in the rest of your 
hygiene filters.


I also believe that mailing lists need to evolve with the times to 
support the current standards.  IMHO they don't get a pass because they 
are mailing lists and have always worked that way.


One doesn’t communicate with folks who chose (or let their service 
provider chose) not to receive email accordingly existing standards. 


Industry standards change, and senders need to keep up with the times.

What those standards are and how appropriate they are is independent.



--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

Weekly Routing Table Report

[Routing Analysis Role Account]

This is an automated weekly mailing describing the state of the Internet
Routing Table as seen from APNIC's router in Japan.

The posting is sent to APOPS, NANOG, AfNOG, SANOG, PacNOG, SAFNOG
TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG and the RIPE Routing WG.

Daily listings are sent to bgp-st...@lists.apnic.net

For historical data, please see http://thyme.rand.apnic.net.

If you have any comments please contact Philip Smith .

Routing Table Report   04:00 +10GMT Sat 23 Feb, 2019

Report Website: http://thyme.rand.apnic.net
Detailed Analysis:  http://thyme.rand.apnic.net/current/

Analysis Summary


BGP routing table entries examined:  738085
Prefixes after maximum aggregation (per Origin AS):  285259
Deaggregation factor:  2.59
Unique aggregates announced (without unneeded subnets):  355452
Total ASes present in the Internet Routing Table: 63351
Prefixes per ASN: 11.65
Origin-only ASes present in the Internet Routing Table:   54573
Origin ASes announcing only one prefix:   23640
Transit ASes present in the Internet Routing Table:8778
Transit-only ASes present in the Internet Routing Table:273
Average AS path length visible in the Internet Routing Table:   4.2
Max AS path length visible:  28
Max AS path prepend of ASN ( 16327)  25
Prefixes from unregistered ASNs in the Routing Table:33
Number of instances of unregistered ASNs:36
Number of 32-bit ASNs allocated by the RIRs:  25890
Number of 32-bit ASNs visible in the Routing Table:   21087
Prefixes from 32-bit ASNs in the Routing Table:   91866
Number of bogon 32-bit ASNs visible in the Routing Table:24
Special use prefixes present in the Routing Table:1
Prefixes being announced from unallocated address space:266
Number of addresses announced to Internet:   2843064419
Equivalent to 169 /8s, 117 /16s and 184 /24s
Percentage of available address space announced:   76.8
Percentage of allocated address space announced:   76.8
Percentage of available address space allocated:  100.0
Percentage of address space in use by end-sites:   99.2
Total number of prefixes smaller than registry allocations:  247477

APNIC Region Analysis Summary
-

Prefixes being announced by APNIC Region ASes:   200761
Total APNIC prefixes after maximum aggregation:   57719
APNIC Deaggregation factor:3.48
Prefixes being announced from the APNIC address blocks:  197814
Unique aggregates announced from the APNIC address blocks:81690
APNIC Region origin ASes present in the Internet Routing Table:9461
APNIC Prefixes per ASN:   20.91
APNIC Region origin ASes announcing only one prefix:   2664
APNIC Region transit ASes present in the Internet Routing Table:   1406
Average APNIC Region AS path length visible:4.1
Max APNIC Region AS path length visible: 26
Number of APNIC region 32-bit ASNs visible in the Routing Table:   4462
Number of APNIC addresses announced to Internet:  769878530
Equivalent to 45 /8s, 227 /16s and 106 /24s
APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431
(pre-ERX allocations)  23552-24575, 37888-38911, 45056-46079, 55296-56319,
   58368-59391, 63488-64098, 64297-64395, 131072-139577
APNIC Address Blocks 1/8,  14/8,  27/8,  36/8,  39/8,  42/8,  43/8,
49/8,  58/8,  59/8,  60/8,  61/8, 101/8, 103/8,
   106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8,
   116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8,
   123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8,
   163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8,
   203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8,
   222/8, 223/8,

ARIN Region Analysis Summary


Prefixes being announced by ARIN Region ASes:218439
Total ARIN prefixes after maximum aggregation:   103601
ARIN Deaggregation factor: 2.11
Prefixes being announced from the ARIN address blocks:   217467
Unique aggregates announced from the ARIN address blocks:104185
ARIN Region origin ASes present in the Internet Routing Table:18390
ARIN Prefixes per ASN:11.83
ARIN Reg

RE: A Zero Spam Mail System [Feedback Request]

[Keith Medcalf]

On Friday, 22 February, 2019 09:36, Miles Fidelman :

> But re. "one doesn't communicate with folks .. etc." --- when one has
> ongoing communication with a large group of people (e.g., an email
> list) --- and a large provider shuts a door, the impact is on more than
> just the customers of that provider

It affects the self-selected group of folks who chose to invest an inherently 
untrustworthy "provider" with trusted status.

In other words they chose their petard willingly and with full knowledge and 
were hoisted by it.

Their swinging and choking is merely the logical outcome of their own choices.

You could be a good nanny and not allow folks to do stupid things -- but where 
would that get you?  As a responsible adult it is far better to allow children 
to make their own foolish mistakes and suffer the consequences thereof in the 
hopes that they will not be so foolish the next time around.

Some, however, never learn and the attempts to remedy ignorance with a 
clue-by-four are fruitless.

When being chased by bears and wolves it is clearly advantageous to permit the 
feeble and slow to jolly-along so they may preferentially satiate the bears and 
wolves.

---
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.

Re: A Zero Spam Mail System [Feedback Request]

[Miles Fidelman]

On 2/22/19 11:28 AM, John Curran wrote:


On 22 Feb 2019, at 9:58 AM, Miles Fidelman  wrote:

On 2/22/19 10:07 AM, John Curran wrote:


On 22 Feb 2019, at 7:08 AM, Miles Fidelman  wrote:

On 2/22/19 12:03 AM, John Curran wrote:


Either way, until such time your solution is deployed widely enough to 
significantly impact network operations, it’s unlikely to be a particularly 
relevant topic for discussion here.


Notable exception:  DMARC.  Broke email lists everywhere - including those that 
folks use to solve problems on the net. Heck, it broke the ietf email list.

Indeed - while a self-inflicted injury on its customers, the network effects of 
massive operating scale effectively transition the problem space from private 
actor to public…

hence not an notable exception, but an actual example of "deployed widely 
enough”

Hmmm  But wasn't the initial impact of DMARC that so few senders of email 
had implemented it?

If you (or your email service provider) deploy an optional solution (e.g. DMARC 
p=reject) that prevents you from receiving email from mailing lists sending in 
conformance with existing standards, then that’s your choice.

Expecting that others will automatically change their behavior (such as 
wrapping email from mailing lists) isn’t reasonable - you’ve effectively 
decided (or let your provider decide) that you don’t want existing 
communications to work for some categories of standard-compliant email.   The 
alternative is ‘Internet Coordination’, but that requires actually coordination 
before making major changes that will break things.


Also, the impact wasn't just on customers, but on trading partners & 
communities - communications being a two way street and all.

One doesn’t communicate with folks who chose (or let their service provider 
chose) not to receive email accordingly existing standards.
In any case, irrelevant to the dombox situation, unless/until someone actually 
deploys at a scale large enough to require consideration.

Not relevant to the dombox approach - though, in fairness, haven't waded 
into it deep enough to conclude that.


But re. "one doesn't communicate with folks .. etc." --- when one has 
ongoing communication with a large group of people (e.g., an email list) 
--- and a large provider shuts a door, the impact is on more than just 
the customers of that provider


Miles




--
In theory, there is no difference between theory and practice.
In practice, there is.   Yogi Berra

Re: A Zero Spam Mail System [Feedback Request]

[John Curran]

On 22 Feb 2019, at 9:58 AM, Miles Fidelman  wrote:
> 
> On 2/22/19 10:07 AM, John Curran wrote:
> 
>> On 22 Feb 2019, at 7:08 AM, Miles Fidelman  
>> wrote:
>>> On 2/22/19 12:03 AM, John Curran wrote:
>>> 
 Either way, until such time your solution is deployed widely enough to 
 significantly impact network operations, it’s unlikely to be a 
 particularly relevant topic for discussion here.
 
>>> Notable exception:  DMARC.  Broke email lists everywhere - including those 
>>> that folks use to solve problems on the net. Heck, it broke the ietf email 
>>> list.
>> Indeed - while a self-inflicted injury on its customers, the network effects 
>> of massive operating scale effectively transition the problem space from 
>> private actor to public…
>> 
>> hence not an notable exception, but an actual example of "deployed widely 
>> enough”
> 
> Hmmm  But wasn't the initial impact of DMARC that so few senders of email 
> had implemented it? 

If you (or your email service provider) deploy an optional solution (e.g. DMARC 
p=reject) that prevents you from receiving email from mailing lists sending in 
conformance with existing standards, then that’s your choice.

Expecting that others will automatically change their behavior (such as 
wrapping email from mailing lists) isn’t reasonable - you’ve effectively 
decided (or let your provider decide) that you don’t want existing 
communications to work for some categories of standard-compliant email.   The 
alternative is ‘Internet Coordination’, but that requires actually coordination 
before making major changes that will break things. 

> Also, the impact wasn't just on customers, but on trading partners & 
> communities - communications being a two way street and all.

One doesn’t communicate with folks who chose (or let their service provider 
chose) not to receive email accordingly existing standards. 
In any case, irrelevant to the dombox situation, unless/until someone actually 
deploys at a scale large enough to require consideration. 

/John

Re: A Zero Spam Mail System [Feedback Request]

[Miles Fidelman]

On 2/22/19 10:07 AM, John Curran wrote:


On 22 Feb 2019, at 7:08 AM, Miles Fidelman  wrote:

On 2/22/19 12:03 AM, John Curran wrote:


Either way, until such time your solution is deployed widely enough to 
significantly impact network operations, it’s unlikely to be a particularly 
relevant topic for discussion here.


Notable exception:  DMARC.  Broke email lists everywhere - including those that 
folks use to solve problems on the net. Heck, it broke the ietf email list.

Indeed - while a self-inflicted injury on its customers, the network effects of 
massive operating scale effectively transition the problem space from private 
actor to public…

hence not an notable exception, but an actual example of "deployed widely 
enough”



Hmmm  But wasn't the initial impact of DMARC that so few senders of 
email had implemented it?  Also, the impact wasn't just on customers, 
but on trading partners & communities - communications being a two way 
street and all.


Miles Fidelman



--
In theory, there is no difference between theory and practice.
In practice, there is.   Yogi Berra

Re: A Zero Spam Mail System [Feedback Request]

[John Curran]

On 22 Feb 2019, at 7:08 AM, Miles Fidelman  wrote:
> 
> On 2/22/19 12:03 AM, John Curran wrote:
> 
>> Either way, until such time your solution is deployed widely enough to 
>> significantly impact network operations, it’s unlikely to be a particularly 
>> relevant topic for discussion here.
>> 
> Notable exception:  DMARC.  Broke email lists everywhere - including those 
> that folks use to solve problems on the net. Heck, it broke the ietf email 
> list.

Indeed - while a self-inflicted injury on its customers, the network effects of 
massive operating scale effectively transition the problem space from private 
actor to public…  

hence not an notable exception, but an actual example of "deployed widely 
enough”

/John

Re: A Zero Spam Mail System [Feedback Request]

[Mike Meredith]

On Wed, 20 Feb 2019 19:01:40 -0700, "Forrest Christian (List Account)"
 may have written:
> On Wed, Feb 20, 2019 at 1:24 PM Matthew Black 
> wrote:
> > Have you ever created a sendmail.cf without using M4?  
> 
> I still believe that sendmail is Alien technology.  How else can one
> explain sendmail.cf?And although I can't say for sure that I

I always thought of sendmail.cf as a language for writing MTAs in. I did do
*bits* in sendmail.cf but switched to Exim before I got too damaged. 

> sendmail.cf file which wasn't working as one would expect.   I'm also
> not 100% certain that m4 was even an option for the first sendmail

It wasn't a Sendmail 8 introduction perhaps?


-- 
Mike Meredith, University of Portsmouth
Chief Systems Engineer, Hostmaster, Security, and Timelord!
 


pgpavwLh2geSD.pgp
Description: OpenPGP digital signature

Re: A Zero Spam Mail System [Feedback Request]

[Miles Fidelman]

On 2/22/19 12:03 AM, John Curran wrote:

Either way, until such time your solution is deployed widely enough to 
significantly impact network operations, it’s unlikely to be a 
particularly relevant topic for discussion here.


Notable exception:  DMARC.  Broke email lists everywhere - including 
those that folks use to solve problems on the net. Heck, it broke the 
ietf email list.


There might be a warning in there - when someone big "innovates" - say 
Google turning on DMARC rejection, for gmail - that can have rather huge 
operational impacts.  Still gives me nightmares on occasion (I run a 
bunch of small lists).


Sigh...

Miles Fidelman



--
In theory, there is no difference between theory and practice.
In practice, there is.   Yogi Berra

Re: sendmail.cf

[Bjørn Mork]

b...@theworld.com writes:

> The predecessor to sendmail was delivermail, 1979, also written by
> Eric Allman.
>
>   https://en.wikipedia.org/wiki/Delivermail

Damn.  Now you made me read RFC801 and wonder why we didn't have an
updated version for the IPv6 transition.  Or: Where would the Internet
have been today without that very explicit "complete switch over" goal?


Bjørn