Re: [mailop] change at gmail???

[Shawn K. Hall]

> I guess what I'm trying to understand is why anyone would 
> base their acceptance or rejection on the 822 From: header.  
> It seems that this causes mailing list managers to have to 
> jump through hoops to rewrite the From: header in strange ways.

Mostly because there are other reasons to munge the header. Failing to
do so, for example, can violate SPF, DKIM, DMARC, PGP and other add-ons
which rely upon specific structures within the header to operate.

-S 



___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] "One-Click" List-Unsubscribe URIs

[Shawn K. Hall]

> You demonstrated the need for a flag day when you stated that 
> the ESPs need to give the ISPs "a hint" that things are 
> changing. Expecting every ESP to contact every ISP is ridiculous. 

No, what he said was that ESPs *could* give a hint. All RFCs and IETF
recommendations are just that - recommendations. Nobody is under any
undue influence to change the way they do things or to implement a new
feature. The only side effect is that eventually you will be outmoded by
those who do implement the new features and capabilities described in
newer recommendations.

An RFC 822 email server is perfectly able to send and receive mail
today. It will work whether or not SSL, TLS, SPF, DKIM, DMARC or
whatever the new post-facto implementations may offer. It will not have
all the same features, and some operators may *choose* to deny mail from
the server for neglecting to implement any one or all of the above, but
the recommendation stands on it's own to be implemented or ignored by
whoever opts in to using it.

That someone is pushing for more effective MUA hints for list management
isn't a bad thing, it's just got to get a lot of traction before it's
useful.

-S


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] "One-Click" List-Unsubscribe URIs

[Shawn K. Hall]

+1. This was what I was thinking when I read it, too.

-S
 

> -Original Message-
> From: mailop [mailto:mailop-boun...@mailop.org] On Behalf Of 
> John Levine
> Sent: Thursday, June 09, 2016 09:11
> To: mailop@mailop.org
> Cc: tobias.herk...@optivo.de
> Subject: Re: [mailop] "One-Click" List-Unsubscribe URIs
> 
> >It's a public document and I welcome requests with updates...
> >https://github.com/Lockhead/oneclick/blob/master/draft-herkul
> a-oneclick.txt
> 
> Hmmn.  One the one hand, I'm definitely in favor of making it as easy
> as possible for people to make the mail go away.
> 
> On the other hand, this particular proposal is a horrible misuse of
> both http GET and of the list-unsubscribe header.  The http specs are
> quite clear that GET is not supposed to change the state on the web
> server.  For that you use POST or PUT.  It is also a bad idea to try
> to redefine the List-Unsubscribe header which has meant the same thing
> for 18 years.
> 
> Fortunately, this is not hard to fix.  Let's invent a new header,
> list-unsubscribe-post, which one can use in conjunction with
> list-unsubscribe, e.g.
> 
>  List-Unsubcribe: 
>  List-Unsubscribe-Post: mailaddr=some...@receipient.de=0209023
> 
> This says to do a POST to the URL in the list-unsubscribe, with the
> fields in the list-unsubscribe-post as the data to the POST.  MUAs
> that don't understand the new field can still do a GET to the URL
> which will do whatever it does, probably show you a page with a
> confirmation button that does a POST.
> 
> This should be easy to implement, since I've never seen an http
> library that could do GET that can't also do POST, and this avoids
> both the semantic problem of GET, and the unintended unsubs by
> filterware that poke all the URLs just to see what will happen.
> 
> R's,
> John
> 
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
> 


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Microsoft/Hotmail discards mails

[Shawn K. Hall]

> You're saying that, simply because a sender or recipient 
> MIGHT be in Germany, that my US-based mail server has to send 
> an NDR? And risk getting added to a "backscatter" RBL?

No, you also have the option of delivering it to the user in a method
that equates to delivery, such as delivering to their spam/junk folder.

-S


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop