Re: [Mailman-Users] cause of bounces

[Lindsay Haisley]

On Wed, 2017-10-18 at 12:38 +0900, Stephen J. Turnbull wrote:
> This whole thread reminds me of an evangelical arguing with a Jesuit.
> 2000 years of Bible study does make for strong debating!

Welll  Spending much time reading RFCs can certainly put one in a
biblical frame of mind ;)  Lots of SHOULD, MUST and MAY therein.

-- 
Lindsay Haisley   | "The first casualty when
FMP Computer Services | war comes is truth."
512-259-1190  |
http://www.fmp.com| -- Hiram W Johnson

--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] cause of bounces

[Stephen J. Turnbull]

This whole thread reminds me of an evangelical arguing with a Jesuit.
2000 years of Bible study does make for strong debating!

Please note that the Sender/From distinction *and* the semantic
interpretations of those fields go back to RFC 733 (1977!) at least,
and the Society of Jesus, er, IETF has refused to change those
semantics on three occasions separated by about a decade apiece (RFCs
822, 2822 = STD 11 IIRC, and 5322).

There are strong reasons, founded in human behavior, for this standard.

Mark Sapiro writes:
 > On 10/17/2017 06:28 PM, Lindsay Haisley wrote:
 > > 
 > > Yes, technically I know, but this kind of stuff makes my head hurt and
 > > my hats to change colors, so I fall back on "If it works, don't fix
 > > it".
 > 
 > 
 > I hear that and I feel your pain.  Somehow it was all simpler when I was
 > younger, and I don't think it was just because I was younger.

A big 10-4 and PLOS 1 to everything you say, Mark!

Steve
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] Mail Delivery

[David Andrews]

At 08:23 PM 10/17/2017, Mark Sapiro wrote:
On 10/17/2017 05:32 PM, David Andrews wrote: > 
At one time I set > Reply-To: header munging > 
under general settings to Yes. Some of my users 
used a screen reader > that balked unless the 
header was munged, for some reason.  Well 
that > software has gone away, and ISP's are 
much pickier these days, with MARC > and dkim 
and SPF etc. Would this setting cause me 
delivery problems ?? > Should I go back and 
change it on older lists. I no longer set it 
to > yes, leave it at no, its default. By "set 
Reply-To: header munging under general settings 
to Yes" I assume you mean reply_goes_to_list = 
This List, but I'm not sure what you're asking. 
Reply-To: header munging is controversial and is 
a religious war. Mailman developers think it 
shouldn't be done, but many think it should be 
which is why the option exists. I am not aware 
of message delivery issues one way or the other, 
but there is an issue with Thunderbird and 
possibly other MUAs. Recent T'bird has changed 
so that if you are looking at a list post with a 
Reply-To: to the list and you do a simple reply 
or control-R, the reply will be addressed to the 
From: and not the list. More recent T'bird has a 
config editor option to restore the old 
behavior, but it's not the default. See these 
threads for all the gory details: 
 
 
 
-- Mark Sapiro The 
highway is for gamblers, San Francisco Bay Area, California


I didn't mean "reply goes to list" but you 
answered my question, as usual!  Thanks!


Dave




---
This email has been checked for viruses by AVG.
http://www.avg.com

--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] cause of bounces

[Mark Sapiro]

On 10/17/2017 06:28 PM, Lindsay Haisley wrote:
> 
> Yes, technically I know, but this kind of stuff makes my head hurt and
> my hats to change colors, so I fall back on "If it works, don't fix
> it".


I hear that and I feel your pain.  Somehow it was all simpler when I was
younger, and I don't think it was just because I was younger.

-- 
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] cause of bounces

[Lindsay Haisley]

On Tue, 2017-10-17 at 17:33 -0700, Mark Sapiro wrote:
> In another thread on mailman-developers, I discussed organizational
> domains with Lindsay, so I assumed he knew.

Yes, technically I know, but this kind of stuff makes my head hurt and
my hats to change colors, so I fall back on "If it works, don't fix
it". The pieces I pulled out of MM code work, and I've set up a cron
job to pull the org domains db to a local server where it comes up
fast, but with everything I'm doing, learning how the cow eats the
cabbages in this kind of thing is pretty much on a need-to-know basis.

-- 
Lindsay Haisley   | "The first casualty when
FMP Computer Services | war comes is truth."
512-259-1190  |
http://www.fmp.com| -- Hiram W Johnson

--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] Mail Delivery

[Mark Sapiro]

On 10/17/2017 05:32 PM, David Andrews wrote:
> At one time I set
> Reply-To: header munging
> under general settings to Yes. Some of my users used a screen reader
> that balked unless the header was munged, for some reason.  Well that
> software has gone away, and ISP's are much pickier these days, with MARC
> and dkim and SPF etc. Would this setting cause me delivery problems ??
> Should I go back and change it on older lists. I no longer set it to
> yes, leave it at no, its default.


By "set Reply-To: header munging under general settings to Yes" I assume
you mean reply_goes_to_list = This List, but I'm not sure what you're
asking. Reply-To: header munging is controversial and is a religious
war. Mailman developers think it shouldn't be done, but many think it
should be which is why the option exists.

I am not aware of message delivery issues one way or the other, but
there is an issue with Thunderbird and possibly other MUAs. Recent
T'bird has changed so that if you are looking at a list post with a
Reply-To: to the list and you do a simple reply or control-R, the reply
will be addressed to the From: and not the list. More recent T'bird has
a config editor option to restore the old behavior, but it's not the
default.

See these threads for all the gory details:





-- 
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] cause of bounces

[Mark Sapiro]

On 10/17/2017 04:46 PM, Grant Taylor via Mailman-Users wrote:
> 
> I decided to see if there was an update to RFC 5322, and lo and behold
> there is.  RFC 6854, which specifically updates RFC 5322 section 3.6.2
> and allows group address syntax exists.
> 
> TL;DR:  From: can now contain a Group address / name, which can zero or
> one or more mailbox addresses.
> 
> I feel like RFC 6854 provides some light at the end of the tunnel and
> allows mailing list managers to modify the From: to be the group,
> including the Group's address.


Group address syntax is something else. it is a specific syntax which is
a name followed literally by a colon followed by a list of zero or more
mailboxes (email addresses) and terminated by a semicolon.

E.g., from the RFC

   Second, consider an email message that is meant to be "from" the two
   managing partners of a business, Ben and Carol, and that is sent by
   their assistant, Dave.  This message could always have been presented
   this way:

  From: b...@example.com,ca...@example.com
  Sender: d...@example.com

   This change allows it to be represented this way:

  From: Managing Partners:b...@example.com,ca...@example.com;
  Sender: d...@example.com

The group syntax has always been allowed in To: and some other headers.
RFC 6854 just extends it to From:

This is most commonly seen with some MUAs when all the recipients are
Bccs, the message is

To: undisclosed recipients:;

> Sender: is not needed because it would be the same as the Group's from
> address.


There's no such thing as a group's address unless the addresses are
listed along with the group name.

Anyway, using a group name alone as From: avoids DMARC as there is no
From: address domain for a DMARC lookup.


> Similarly, I found wording in RFC 5322 that indicates that a user agent
> forwarding a message, is actually a new message.  Section 3.6.6 has the
> following copy:
> 
>> Note: Reintroducing a message into the transport system and using
>> resent fields is a different operation from "forwarding".
>>  "Forwarding" has two meanings: One sense of forwarding is that a mail
>> reading program can be told by a user to forward a copy of a message
>> to another person, making the forwarded message the body of the new
>> message.  A forwarded message in this sense does not appear to have
>> come from the original sender, but is an entirely new message from the
>> forwarder of the message.  Forwarding may also mean that a mail
>> transport program gets a message and forwards it on to a different
>> destination for final delivery.  Resent header fields are not intended
>> for use with either type of forwarding.


That type of forwarding is exactly what is done by Mailman's DMARC Wrap
Message action and that is the reason that action exists. Because in
that case the list message is RFC 5322 compliant. However many MUAs,
particularly mobile apps, have difficulty rendering such a message in a
good way, so Wrap Message isn't always the best option.

-- 
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

[Mailman-Users] Mail Delivery

[David Andrews]

At one time I set
Reply-To: header munging
under general settings to Yes. Some of my users used a screen reader 
that balked unless the header was munged, for some reason.  Well that 
software has gone away, and ISP's are much pickier these days, with 
MARC and dkim and SPF etc. Would this setting cause me delivery 
problems ?? Should I go back and change it on older lists. I no 
longer set it to yes, leave it at no, its default.


Dave



---
This email has been checked for viruses by AVG.
http://www.avg.com

--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] cause of bounces

[Mark Sapiro]

On 10/17/2017 05:04 PM, Grant Taylor via Mailman-Users wrote:
> On 10/17/2017 05:07 PM, Mark Sapiro wrote:
> 
> My brain is failing to translate "corresponding organizational domains"
> to "sub-domains" properly and what that means for strict vs relaxed.


In another thread on mailman-developers, I discussed organizational
domains with Lindsay, so I assumed he knew.

In summary, every domain has a corresponding organizational domains
which may be the same or a "super" domain. In short, the organizational
domain is the domain that might be found in whois. For "common" tlds
like .com, .org, net, .edu, etc. the organizational domain is the top
two levels. E.g. the organizational domain for
some.sub.domain.example.com is example.com, but it's much more
complicated than that. See  if you want
to know more.


>> So the bottom line is as an "unaffiliated" relay without munging From:,
>> SPF will never pass for DMARC and DKIM will only pass if you don't
>> transform the message in ways that break the From: domain's DKIM
>> signature.
> 
> I assume that you're talking about the SMTP envelope from and not the
> From: header.


No. I could have slipped, but when I write From: domain, I mean the
domain of the address in the From: header (That's what DMARC is all
about - verifying that the message actually came from the domain of the
address in the From: header). If I mean the domain of the envelope from,
I try to use that phrase, but in the context of DMARC that domain is
only relevant for SPF and only if it "aligns" with the From: domain.

-- 
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] cause of bounces

[Grant Taylor via Mailman-Users]

On 10/17/2017 06:00 PM, Dimitri Maziuk wrote:
I've a "tactical foliage green" kufiah, best five bucks I ever spent on 
an article of clothing.


I like it.

The point was that SPF will flag messages with ineptly spoofed From 
addresses, and I don't seem to see any of those anymore.


;-)

As for DKIM, say you proved that the message was altered after the 
postmaster@yourdomain was done with it. Now what? Depending on how you 
look at it, the standard says either
- now pretend you don't know if it was altered (in your interpretation: 
"maliciously") or not, or

- (in Mark's version) assume anything not signed is malicious and invalid.
I strongly dislike either alternative.


I personally work under the assumption that:

If DKIM signature validates, then I consider the message good.

If DKIM signature fails, then there is something wrong with the message, 
and treat it suspiciously.  Read:  I increment the spam score.  (If the 
spam score is high enough I reject the message at SMTP time.)


If there is no DKIM signature, I continue processing normally.



--
Grant. . . .
unix || die

--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] cause of bounces

[Grant Taylor via Mailman-Users]

On 10/17/2017 05:07 PM, Mark Sapiro wrote:

The reference is the DMARC standard RFC 7489
.


I need to go back and re-read that again.


It's more complicated than the above.  There is a concept of domain
alignment. Alignment is satisfied in either "strict" or relaxed "mode".
A dmarc policy record may optionally specify either mode for DKIM
alignment or SPF alignment or both with the default being "relaxed.


My brain is failing to translate "corresponding organizational domains" 
to "sub-domains" properly and what that means for strict vs relaxed.



For a message to pass DMARC it must meet 1 of 2 requirements.

1) It must possess a valid DKIM signature from a domain aligned with the
From: domain. In strict mode aligned means equal. In relaxed mode
aligned means the corresponding organizational domains are equal.

or

2) It must pass SPF. SPF works on the domain of the SMTP envelope from.
Thus for SPF to pass, that domain must publish an SPF record specifying
the IP of the sending server as a permitted sender. Further, for DMARC
the envelope from (SPF) domain must align with the From: domain. Again,
in strict mode aligned means equal. In relaxed mode aligned means the
corresponding organizational domains are equal.


As I was reading this, I realized that I may have conflated DMARC 
reporting with DMARC pass / fail.



Note that if you are relaying mail, SPF probably will pass for your
server if the envelope from domain is your server, but it won't align
with an unmunged From: domain and if it does align because you didn't
rewrite it, SPF will fail unless the original sending domain publishes
SPF that permits your server as a sender.


*nod*


So the bottom line is as an "unaffiliated" relay without munging From:,
SPF will never pass for DMARC and DKIM will only pass if you don't
transform the message in ways that break the From: domain's DKIM signature.


I assume that you're talking about the SMTP envelope from and not the 
From: header.



There is a remote possibility that the originating domain that publishes
a DMARC policy relies on SPF and doesn't DKIM sign the message in which
case, unmumged, relayed mail will almost certainly fail DMARC.


I know someone who is doing exactly that, purely for the purpose of 
receiving the feedback reports.




--
Grant. . . .
unix || die

--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] cause of bounces

[Dimitri Maziuk]

On 10/17/2017 05:36 PM, Grant Taylor via Mailman-Users wrote:

> /me wonders what color Dimitri's hat is.  ;-)  #knowtheyenemy

I've a "tactical foliage green" kufiah, best five bucks I ever spent on
an article of clothing.

The point was that SPF will flag messages with ineptly spoofed From
addresses, and I don't seem to see any of those anymore.

As for DKIM, say you proved that the message was altered after the
postmaster@yourdomain was done with it. Now what? Depending on how you
look at it, the standard says either
- now pretend you don't know if it was altered (in your interpretation:
"maliciously") or not, or
- (in Mark's version) assume anything not signed is malicious and invalid.
I strongly dislike either alternative.

-- 
Dimitri Maziuk
Programmer/sysadmin
BioMagResBank, UW-Madison -- http://www.bmrb.wisc.edu



signature.asc
Description: OpenPGP digital signature
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] cause of bounces

[Grant Taylor via Mailman-Users]

On 10/17/2017 03:54 PM, Mark Sapiro wrote:

What I mean is as I posted previously
, 
RFC 5322 says the From: contains the "the mailbox(es) of the person(s) 
or system(s) responsible for the writing of the message." and munging 
the From: to the list address is not compliant with this requirement.


ACK  That's what I figured you were talking about, but figured I ask 
instead of assuming.


(Long pause to pontificate and research.)

I decided to see if there was an update to RFC 5322, and lo and behold 
there is.  RFC 6854, which specifically updates RFC 5322 section 3.6.2 
and allows group address syntax exists.


TL;DR:  From: can now contain a Group address / name, which can zero or 
one or more mailbox addresses.


I feel like RFC 6854 provides some light at the end of the tunnel and 
allows mailing list managers to modify the From: to be the group, 
including the Group's address.


Sender: is not needed because it would be the same as the Group's from 
address.


Similarly, I found wording in RFC 5322 that indicates that a user agent 
forwarding a message, is actually a new message.  Section 3.6.6 has the 
following copy:


	Note: Reintroducing a message into the transport system and using 
resent fields is a different operation from "forwarding". 
 "Forwarding" has two meanings: One sense of forwarding is that a 
mail reading program can be told by a user to forward a copy of a 
message to another person, making the forwarded message the body 
of the new message.  A forwarded message in this sense does not 
appear to have come from the original sender, but is an entirely 
new message from the forwarder of the message.  Forwarding may 
also mean that a mail transport program gets a message and 
forwards it on to a different destination for final delivery. 
 Resent header fields are not intended for use with either type of 
forwarding.


I consider a mailing list manager to be a fancy MUA that automatically 
forwards in this context.


I know that this copy is addressing the Recent-* headers, but I think 
that it clearly describes that a forwarded message (like an MLM 
generates) is a new message, and as such should reflect the person ~> 
entity (read: MLM) that is sending the new message.


In the spirit of DMARC mitigation, we all agree that it is a necessary 
evil, at least in some cases, but that doesn't change the fact that it 
is an 'evil'.


I will concede that modifying the From: header is a questionable 
technique.  -  However I think it is done with a white hat spirit. 
Further, I feel like RFC 6854 helps enable (if not indirectly condone) 
use of said technique.




--
Grant. . . .
unix || die

--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] cause of bounces

[Lindsay Haisley]

On Tue, 2017-10-17 at 16:20 -0700, Mark Sapiro wrote:
> See my post that I was still typing when this was sent
>  html>.

> 2) It must pass SPF. SPF works on the domain of the SMTP envelope from.
> Thus for SPF to pass, that domain must publish an SPF record specifying
> the IP of the sending server as a permitted sender. Further, for DMARC
> the envelope from (SPF) domain must align with the From: domain. Again,
> in strict mode aligned means equal. In relaxed mode aligned means the
> corresponding organizational domains are equal.

OK, thanks. This is clear, and useful information. fmp.com publishes a
proper SPF record, and with regard to the mail server DMARC mitigation
program I wrote for Courier, the envelope sender is "al...@fmp.com",
which can possibly be adjusted, but which matches "postmas...@fmp.com"
which I'm using for the body From header on munged emails, and on top
of this FMP publishes "a mx ptr ip4:198.58.125.221 mx:linode.fmp.com
-all" for SPF, which grabs just about everything and should be OK.

-- 
Lindsay Haisley   | "The first casualty when
FMP Computer Services | war comes is truth."
512-259-1190  |
http://www.fmp.com| -- Hiram W Johnson

--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] cause of bounces

[Mark Sapiro]

On 10/17/2017 03:38 PM, Lindsay Haisley wrote:
> 
> Any system which REQUIRES DKIM validation to pass is out of compliance
> with RFCs, as I understand it. A DKIM signature which doesn't validate
> MUST be treated the same as no DKIM signature at all.


Actually, it's SHOULD, not MUST in the latest RFC.

And, DMARC doesn't exactly REQUIRE DKIM validation to pass. DMARC treats
a message with no DKIM signature the same as one with an invalid
signature so it is compliant in that sense.


> And I don't believe we're dealing with SPF here, just alignment between
> the domain of an email's author (From) and the IP address of the system
> communicating SMTP server from which the recipient's SMTP server
> received the mail. Correct me if I'm wrong on this, but I don't believe
> a SPF record in DNS is required.


It's not required, but it can enable DMARC to pass IF it passes and the
envelope from domain aligns with the From: domain.

See
.

-- 
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] cause of bounces

[Mark Sapiro]

On 10/17/2017 03:15 PM, Lindsay Haisley wrote:
> 
> Just as an aside here, my understanding is that validation of an email
> by DMARC requires ONE of two things: EITHER the DKIM signature in the
> email must validate, OR the domain of the From body header must resolve
> to the IP address of the Sender system (list server or mail reflector).
> Is this correct? Where's a reference on this?


The reference is the DMARC standard RFC 7489
.

It's more complicated than the above.  There is a concept of domain
alignment. Alignment is satisfied in either "strict" or relaxed "mode".
A dmarc policy record may optionally specify either mode for DKIM
alignment or SPF alignment or both with the default being "relaxed.

For a message to pass DMARC it must meet 1 of 2 requirements.

1) It must possess a valid DKIM signature from a domain aligned with the
From: domain. In strict mode aligned means equal. In relaxed mode
aligned means the corresponding organizational domains are equal.

or

2) It must pass SPF. SPF works on the domain of the SMTP envelope from.
Thus for SPF to pass, that domain must publish an SPF record specifying
the IP of the sending server as a permitted sender. Further, for DMARC
the envelope from (SPF) domain must align with the From: domain. Again,
in strict mode aligned means equal. In relaxed mode aligned means the
corresponding organizational domains are equal.

Note that if you are relaying mail, SPF probably will pass for your
server if the envelope from domain is your server, but it won't align
with an unmunged From: domain and if it does align because you didn't
rewrite it, SPF will fail unless the original sending domain publishes
SPF that permits your server as a sender.

So the bottom line is as an "unaffiliated" relay without munging From:,
SPF will never pass for DMARC and DKIM will only pass if you don't
transform the message in ways that break the From: domain's DKIM signature.

There is a remote possibility that the originating domain that publishes
a DMARC policy relies on SPF and doesn't DKIM sign the message in which
case, unmumged, relayed mail will almost certainly fail DMARC.

-- 
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] cause of bounces

[Lindsay Haisley]

On Tue, 2017-10-17 at 16:28 -0600, Grant Taylor via Mailman-Users
wrote:
> That is a per domain setting left up to the DMARC publisher.

The DMARC publisher is not the system refusing delivery. The publisher
advertises a policy. The receiving system honors it, or not.

> At least my understanding is that you can specify any of the
> following=20
> conditions to cause DMARC to pass / fail.
> 
> 1) /Only/ SPF
> 2) /Only/ DKIM
> 3) SPF /or/ DKIM
> 4) SPF /and/ DKIM

Any system which REQUIRES DKIM validation to pass is out of compliance
with RFCs, as I understand it. A DKIM signature which doesn't validate
MUST be treated the same as no DKIM signature at all.

And I don't believe we're dealing with SPF here, just alignment between
the domain of an email's author (From) and the IP address of the system
communicating SMTP server from which the recipient's SMTP server
received the mail. Correct me if I'm wrong on this, but I don't believe
a SPF record in DNS is required.

-- 
Lindsay Haisley   | "The first casualty when
FMP Computer Services | war comes is truth."
512-259-1190  |
http://www.fmp.com| -- Hiram W Johnson

--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] cause of bounces

[Grant Taylor via Mailman-Users]

On 10/17/2017 11:45 AM, Dimitri Maziuk wrote:

If these actually exist, my spamassassin has been delivering to
/dev/null for quite some time now. My impression is they largely died
off, possibly thanks to adoption of SPF.


If these actually exist?  -  I'm talking about someone configuring their 
old email address to forward to their new email address.  -  I just 
happened to extrapolate out further.  I.e. old college email forwards to 
Yahoo, which forwards to Gmail, etc.  -  I suspect the single level 
forwarding is quite common.


Are we talking about the same thing?  I.e. .forward files?  Or are you 
thinking something more nefarious?



Now it is much easier and cheaper to send spam from botnets of perfectly
legitimate pwn3d peecees. Or to anonymously register a perfectly valid
domain (e.g. tnеtсоnsulting.net -- there's 3 "language-specific script"
chars in there), add all the DMARC embellishments, and send perfectly
compliant spam as gtaylor from there.


I scowl at you sir.  I dislike being the example.  But I think what you 
did is quite neat and perfectly valid example.  Nicely played sir.


I actually have no idea how to defend against such attacks, save for 
registering all such permutations.


I wonder how some such language-specific script characters would show up 
in logs.  Especially ASCII without UTF support.



For bonus points, pay with stolen credit card number and have your spam
campaign all done by the time visa fraud department calls you domain
registar.


/me wonders what color Dimitri's hat is.  ;-)  #knowtheyenemy



--
Grant. . . .
unix || die

--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] cause of bounces

[Grant Taylor via Mailman-Users]

On 10/17/2017 04:28 PM, Dimitri Maziuk wrote:

Why? If this message doesn't match its signature, then it has been
altered in transit for sure. If were not signed, like when I post from
home (because I can't be arsed to set gpg up on winderz), then there's
no telling if it was or wasn't. One of those things is quite a bit not
like the other.


If I understand your question correctly

DKIM is meant to cryptographically prove that a message is unaltered (*).

I think that DKIM is avoiding the possibility that a message could be 
incidentally modified in transit, i.e. encoding conversion, thus not 
maliciously modified.  As such, DKIM does not penalize for broken 
signatures.  Instead, DKIM rewards valid signatures.


I know it's a small nuanced distinction, but it is there.

* ROPEMAKER further complicates this throwing lots of wrenches in the works.



--
Grant. . . .
unix || die

--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] cause of bounces

[Grant Taylor via Mailman-Users]

On 10/17/2017 04:15 PM, Lindsay Haisley wrote:
Just as an aside here, my understanding is that validation of an email 
by DMARC requires ONE of two things: EITHER the DKIM signature in the 
email must validate, OR the domain of the From body header must resolve 
to the IP address of the Sender system (list server or mail reflector). 
 Is this correct? Where's a reference on this?


That is a per domain setting left up to the DMARC publisher.

At least my understanding is that you can specify any of the following 
conditions to cause DMARC to pass / fail.


1) /Only/ SPF
2) /Only/ DKIM
3) SPF /or/ DKIM
4) SPF /and/ DKIM



--
Grant. . . .
unix || die

--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] cause of bounces

[Dimitri Maziuk]

On 10/17/2017 04:40 PM, Grant Taylor via Mailman-Users wrote:
> On 10/17/2017 03:22 PM, Mark Sapiro wrote:
>> Agreed, but the above imply NOT RFC 5322 compliant.
> 
> Please elaborate, if you're referring to more than From: vs Sent-By:.
> 
>> In other words, an invalid DKIM signature SHOULD be treated no
>> differently from no signature.
> 
> Fair enough. 

Why? If this message doesn't match its signature, then it has been
altered in transit for sure. If were not signed, like when I post from
home (because I can't be arsed to set gpg up on winderz), then there's
no telling if it was or wasn't. One of those things is quite a bit not
like the other.

-- 
Dimitri Maziuk
Programmer/sysadmin
BioMagResBank, UW-Madison -- http://www.bmrb.wisc.edu



signature.asc
Description: OpenPGP digital signature
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] cause of bounces

[Lindsay Haisley]

On Tue, 2017-10-17 at 14:54 -0700, Mark Sapiro wrote:
> In the spirit of DMARC mitigation, we all agree that it is a necessary
> evil, at least in some cases, but that doesn't change the fact that it
> is an 'evil'.

Just as an aside here, my understanding is that validation of an email
by DMARC requires ONE of two things: EITHER the DKIM signature in the
email must validate, OR the domain of the From body header must resolve
to the IP address of the Sender system (list server or mail reflector).
Is this correct? Where's a reference on this?

-- 
Lindsay Haisley   | "The first casualty when
FMP Computer Services | war comes is truth."
512-259-1190  |
http://www.fmp.com| -- Hiram W Johnson
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] cause of bounces

[Mark Sapiro]

On 10/17/2017 02:40 PM, Grant Taylor via Mailman-Users wrote:
> On 10/17/2017 03:22 PM, Mark Sapiro wrote:
>> Agreed, but the above imply NOT RFC 5322 compliant.
> 
> Please elaborate, if you're referring to more than From: vs Sent-By:.


What I mean is as I posted previously
,
RFC 5322 says the From: contains the "the mailbox(es) of the person(s)
or system(s) responsible for the writing of the message." and munging
the From: to the list address is not compliant with this requirement.

In the spirit of DMARC mitigation, we all agree that it is a necessary
evil, at least in some cases, but that doesn't change the fact that it
is an 'evil'.

-- 
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] cause of bounces

[Grant Taylor via Mailman-Users]

On 10/17/2017 03:22 PM, Mark Sapiro wrote:

Agreed, but the above imply NOT RFC 5322 compliant.


Please elaborate, if you're referring to more than From: vs Sent-By:.


In other words, an invalid DKIM signature SHOULD be treated no
differently from no signature.


Fair enough.  -  I suspect DKIM by itself can tolerate that, like you 
are referencing.


I believe the problem is when DMARC is added to the mix, particularly 
with a policy of reject.




--
Grant. . . .
unix || die

--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] cause of bounces

[Mark Sapiro]

On 10/17/2017 10:38 AM, Grant Taylor via Mailman-Users wrote:
> On 10/17/2017 10:55 AM, Christian F Buser via Mailman-Users wrote:
> 
>> However, could you please elaborate whether Mailman (version 2.x or
>> 3.x) or any other mailing list software really follows your ideas?
> 
> Yes!!!  Mailman (and other MLMs) /can/ be configured to be SPF / DKIM /
> DMARC compliant!


Agreed, but the above imply NOT RFC 5322 compliant.


> I don't have the exact step by step details.  -  I'm sure others
> (Mark...) on this list can give specifics on /how/ to configure Mailman.
> 
> The high level as I understand it is to do the following:
> 
> 1) Set dmarc_moderation_action to munge From header.

This is available in both MM 2.1 and 3.1

> 2) Set REMOVE_DKIM_HEADERS to Yes (1) or 2 or 3.

In MM 3, The only options are always remove or never remove. The "remove
only if munging From:" and "rename" options are not in MM 3

However, it SHOULD not be necessary. Section 6.3 of RFC 4871 says in part:

   If the email cannot be verified, then it SHOULD
   be rendered the same as all unverified email regardless of whether or
   not it looks like it was signed.

In other words, an invalid DKIM signature SHOULD be treated no
differently from no signature.


> 3) Send messages from the list address.  I recommend VERP.


Mailman sends (SMTP envelope) all messages from the list-bounces
address. Both MM 2.1 and MM 3 can be configured to VERP some or all
deliveries.


> I would suggest that you also consider adding SPF / DKIM / DMARC for the
> domain of the mailing list to apply similar protections to outgoing
> messages.  However that is not necessary to avoid undesired bounces.


Publishing SPF and DKIM signing outgoing mail are good things.
Publishing a DMARC policy and what policy to publish depend on how your
server is used and what classes of mail it sends. In particular, if
individuals send personal email, possibly to mailing lists From:
addresses in the server's domain, I think publishing a DMARC policy
other than "none" is not a good idea. On the other hand, if you are a
financial institution and all mail From: your domain is official
correspondence between you and clients, you are who DMARC was designed for.

-- 
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] cause of bounces

[Mark Sapiro]

On 10/17/2017 09:10 AM, Grant Taylor via Mailman-Users wrote:
> 
> I know that I am not personally sending this message to anyone other
> than the single address that is the mailman-users mailing list.  -  The
> mailman-users mailing list is what is sending message to all the
> subscribers, *NOT* me.


That is quite true, but in this example, the mailing list is the
'sender' of the message I receive. It is not the 'author' of the
message. You are still the 'author'. RFC 5322, sec 3.6.2 and
predecessors are clear:

   The "From:" field specifies the author(s) of the message,
   that is, the mailbox(es) of the person(s) or system(s) responsible
   for the writing of the message.  The "Sender:" field specifies the
   mailbox of the agent responsible for the actual transmission of the
   message.

-- 
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] cause of bounces

[Dimitri Maziuk]

On 10/17/2017 11:10 AM, Grant Taylor via Mailman-Users wrote:

>  - I *STRONGLY* feel that mailing lists / forwarders / etc are email
> endpoints.  Many of them generate new messages with content based on the
> incoming content.  -  Thus it is perfectly acceptable to do all of the
> above /because/ it is a /new/ and /different/ message.

+1

> Sure, /someone's/ server sent a message to Mike, possibly claiming to be
> from me.  But it was *NOT* /from/ me or my server.  Thus, the message is
> bogus and /should/ be treated as such.

If these actually exist, my spamassassin has been delivering to
/dev/null for quite some time now. My impression is they largely died
off, possibly thanks to adoption of SPF.

Now it is much easier and cheaper to send spam from botnets of perfectly
legitimate pwn3d peecees. Or to anonymously register a perfectly valid
domain (e.g. tnеtсоnsulting.net -- there's 3 "language-specific script"
chars in there), add all the DMARC embellishments, and send perfectly
compliant spam as gtaylor from there.

For bonus points, pay with stolen credit card number and have your spam
campaign all done by the time visa fraud department calls you domain
registar.

-- 
Dimitri Maziuk
Programmer/sysadmin
BioMagResBank, UW-Madison -- http://www.bmrb.wisc.edu



signature.asc
Description: OpenPGP digital signature
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] cause of bounces

[Grant Taylor via Mailman-Users]

On 10/17/2017 10:55 AM, Christian F Buser via Mailman-Users wrote:
I can perfectly follow your thoughts and arguments, they appear to be 
justified and reasonable.


Thank you.  I tried to make them so that people could understand, even 
if they choose to disagree.


However, could you please elaborate whether Mailman (version 2.x or 
3.x) or any other mailing list software really follows your ideas?


Yes!!!  Mailman (and other MLMs) /can/ be configured to be SPF / DKIM / 
DMARC compliant!


If it is just a question of the setup for the mailing list, I would 
expect your instructions on how to set it up properly.


I don't have the exact step by step details.  -  I'm sure others 
(Mark...) on this list can give specifics on /how/ to configure Mailman.


The high level as I understand it is to do the following:

1) Set dmarc_moderation_action to munge From header.
2) Set REMOVE_DKIM_HEADERS to Yes (1) or 2 or 3.
3) Send messages from the list address.  I recommend VERP.

Doing those three things ensures that messages leaving the mailing list 
do not violate the original sending domain's SPF / DKIM / DMARC security 
settings.


I would suggest that you also consider adding SPF / DKIM / DMARC for the 
domain of the mailing list to apply similar protections to outgoing 
messages.  However that is not necessary to avoid undesired bounces.



Thank you, Christian

You're welcome.



--
Grant. . . .
unix || die

--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] cause of bounces

[Christian F Buser via Mailman-Users]

Hello Grant Taylor via Mailman-Users. On Tue, 17 Oct 2017 10:10:56 -0600, you 
wrote:

> Some drive by comments:
> ...

I can perfectly follow your thoughts and arguments, they appear to be justified 
and reasonable. 

However, could you please elaborate whether Mailman (version 2.x or 3.x) or any 
other mailing list software really follows your ideas? If it is just a question 
of the setup for the mailing list, I would expect your instructions on how to 
set it up properly. 

Thank you, Christian 

-- 
Christian F. Buser, Hohle Gasse 6, CH-5507 Mellingen (Switzerland)  
Hilfe fuer Strassenkinder in Ghana: http://www.chance-for-children.org
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] cause of bounces

[Grant Taylor via Mailman-Users]

On 10/14/2017 02:07 PM, Stephen J. Turnbull wrote:

For (2) to make sense, the email provider should have a policy that
prohibits use of its mailboxes to post to mailing lists, and it must
not provide "on behalf of" services such as sending photographs or
newspaper articles using your address in From.  This makes sense for
banks and other financial institutions, and use of DMARC "p=reject"
has pretty much eliminated phishing using mail with real bank
addresses in From.


Some drive by comments:

 - IMHO, "on behalf of" services (I like that description) should be 
sent with a From: address that reflects the service -and- utilize a 
Reply-To: that reflects the email address of the purported sender. 
(Further, the service's From: address /should/ be legitimate and not 
bounce.  But that's more pedantic.)


 - I feel like DMARC is perfectly compatible with mailing lists as long 
as the mailing list is set up to modify the message as it passes through 
the list:


1) Change the From: header to reflect the mailing list.
2) Send the message with an SMTP from reflecting the mailing list. 
(VERP is suggested.)

3) Remove any / all DKIM headers.

 - I *STRONGLY* feel that mailing lists / forwarders / etc are email 
endpoints.  Many of them generate new messages with content based on the 
incoming content.  -  Thus it is perfectly acceptable to do all of the 
above /because/ it is a /new/ and /different/ message.


I know that I am not personally sending this message to anyone other 
than the single address that is the mailman-users mailing list.  -  The 
mailman-users mailing list is what is sending message to all the 
subscribers, *NOT* me.  Both my mail server and the mail list server's 
MTA logs will corroborate this.  -  I think pretending that I am 
/personally/ (thus my MTA is) sending messages to all the subscribers is 
a farce.  Further I believe that said farce is part of (if not the crux 
of) the perceived problems with SPF / DKIM / DMARC on conjunction with 
mailing lists.


Think about it this way.  If Alice sends a message to Bob, who has his 
email configured to forward to Charlie who also forwards to Dave, and so 
on until we reach Mike, I will *STRONGLY* argue that I never sent a 
message to Mike if asked.


Sure, /someone's/ server sent a message to Mike, possibly claiming to be 
from me.  But it was *NOT* /from/ me or my server.  Thus, the message is 
bogus and /should/ be treated as such.


 - I recently compared forwarders / mailing lists to be like phone 
messages.  The person taking the phone message does not pretend to be 
the caller when passing the message along.  Instead the message taker 
typically says something to the effect of "$SoandSo called and left a 
message for you."  The phone message is a /new/ message based on the 
contents of the original call, *NOT* a (replay) of the original call.




--
Grant. . . .
unix || die

--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] cause of bounces

[Dimitri Maziuk]

On 2017-10-16 23:27, mailbox.org wrote:

Thank you Steve!

Now I understand it is not all bad. Just the way that AOIL and YAHOO went about 
it (or something like that).


It's not bad, only it's mostly useless for human people like you and I. 
What good it does is mostly for google-person and yahoo-person and their 
kind.


Dima
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org