Lists and spam prevention / use of Reply-To:

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
25 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Lists and spam prevention / use of Reply-To:

Rick van Rein
Hi,

I've been studying SPF, DKIM, DMARC and a bit of ARC.  And I've been
wondering if a list [including this one] could be more friendly by using
Reply-To: to hold the message sender.

These spam-fighting methods have the greatest difficulty with email
forwarding and lists because:

 - changes to message headers usually invalidate a DKIM message
 - bypass routes usually invalidate SPF settings
 - DMARC requires either to hold _and_ the domain to match the From: header

An indirect MTA cannot produce a DKIM message on the originator's
domain, and DMARC demands that to align with the From: header.

An indirect MTA may alter envelope from to make SPF work, but DMARC
additionally requires the envelope sender to align with the From: header.

A way to send email in line with DMARC might be:

 1. stash the original sender in the Reply-To: header
 2. use a From: header with a list address under the list bounce domain
 3. setup SPF in the list bounce domain
 4. this should pass on DMARC, because SPF passes and DKIM fails


I'd like to learn if this approach is considered sound by the list.


Cheers,

Rick van Rein
Reply | Threaded
Open this post in threaded view
|

Re: Lists and spam prevention / use of Reply-To:

Rick van Rein
Interestingly,

This list is a modest exception -- DKIM should pass through it perfectly,
mostly because it does not change the Subject: From: To: or body.

But the question was about soundness of the general Reply-To: idea anyway.

-Rick
Reply | Threaded
Open this post in threaded view
|

Re: Lists and spam prevention / use of Reply-To:

Benny Pedersen-2
Rick van Rein skrev den 2017-08-28 19:09:
> Interestingly,
>
> This list is a modest exception -- DKIM should pass through it
> perfectly,
> mostly because it does not change the Subject: From: To: or body.
>
> But the question was about soundness of the general Reply-To: idea
> anyway.

i noted that it's possible to get dmarc fail on postfix maillist

its spf none, dkim none, dmarc fail, in my tests, arc is not tested or
planned to be in use

i have configured opendmarc to not reject dmarc fails here for postfix
maillist since i like to stay on the list

thanks for testing it works
Reply | Threaded
Open this post in threaded view
|

Re: Lists and spam prevention / use of Reply-To:

Ralph Seichter
In reply to this post by Rick van Rein
On 28.08.17 17:42, Rick van Rein wrote:

> I've been studying SPF, DKIM, DMARC and a bit of ARC. And I've been
> wondering if a list [including this one] could be more friendly by
> using Reply-To: to hold the message sender.

The Postfix mailing list is "friendly" already. It does not break DKIM
since it does neither mess with From nor add junk to Subject or the
message bodies. Besides, all messages on this list contain the correct
List-FOO headers. As for spam, messages on the Postfix mailing list
usually score with deep negative values in SpamAssassin. You're barking
up the wrong tree here. ;-)

-Ralph
Reply | Threaded
Open this post in threaded view
|

Re: Lists and spam prevention / use of Reply-To:

Benny Pedersen-2
Ralph Seichter skrev den 2017-08-28 22:05:
> usually score with deep negative values in SpamAssassin. You're barking
> up the wrong tree here. ;-)

and Reply-To: is safe to remove in smtp_header_checks

since its not default dkim signed

its not safe to remove in header_checks, if remotes sign it in dkim,
this could be tracked as spam attempt ?
Reply | Threaded
Open this post in threaded view
|

Re: Lists and spam prevention / use of Reply-To:

Noel Jones-2
On 8/28/2017 3:18 PM, Benny Pedersen wrote:
> Ralph Seichter skrev den 2017-08-28 22:05:
>> usually score with deep negative values in SpamAssassin. You're
>> barking
>> up the wrong tree here. ;-)
>
> and Reply-To: is safe to remove in smtp_header_checks

Assuming your users neither use Reply-To: nor find it useful.  Some
of my users do.

>
> since its not default dkim signed
>
> its not safe to remove in header_checks, if remotes sign it in dkim,
> this could be tracked as spam attempt ?

Reply-To: is a valid header used for valid purposes, occasionally
abused by spammers.  It's doubtful the presence of this header,
signed or not, is much of a spam indicator.   Maybe if the reply-to
address is a also a freemail provider.



  -- Noel Jones
Reply | Threaded
Open this post in threaded view
|

Re: Lists and spam prevention / use of Reply-To:

Rick van Rein
In reply to this post by Ralph Seichter
Hello,

I should not have used this list as an example :) because it undermined
my point.

> messages on the Postfix mailing list
> usually score with deep negative values in SpamAssassin. You're barking
> up the wrong tree here. ;-)

My interest in spam is due to the apparent move that email is slowly
going through, from a model where things are accepted by default and
filtered out when suspect, to a model where things have to prove their
salt before being let in.  In that light, DKIM, SPF and DMARC are of
interest to any mail flow.

What I am asking is if the option to place the sender in Reply-To: and
have the list address in From: so it matches the SPF domain and so even
DKIM could be signed by the list would be considered a good or bad idea
by admins running lists.


Cheers,
 -Rick
Reply | Threaded
Open this post in threaded view
|

Re: Lists and spam prevention / use of Reply-To:

Rick van Rein
In reply to this post by Benny Pedersen-2
Hi,

> i noted that it's possible to get dmarc fail on postfix maillist
>
> its spf none, dkim none, dmarc fail, in my tests, arc is not tested or
> planned to be in use


I tested your two emails for DKIM, and both failed for me.
The ones by Noel and Ralph did get through.  I used dkimverify.py
from the dkimpy package, and copy/paste to get the message source
in.

A difference between your DKIM-Signature and the others' is that
you have set c=simple/simple where the others use c=relaxed/relaxed
and c=relaxed/simple.  As a result of this, you are picking on
whitespace modifications in the headers while the others are not:

  To satisfy all requirements, two canonicalization algorithms are
  defined for each of the header and the body: a "simple" algorithm
  that tolerates almost no modification and a "relaxed" algorithm that
  tolerates common modifications such as whitespace replacement and
  header field line rewrapping.

  [Section 3.4 of RFC6376 on DKIM Signatures]

I didn't see any changes in whitespace in my postings to this list,
but that may also be due to normalisation in the spam filter through
which both outgoing and incoming messages pass.

-Rick
Reply | Threaded
Open this post in threaded view
|

Re: Lists and spam prevention / use of Reply-To:

Ralph Seichter
In reply to this post by Rick van Rein
On 29.08.2017 09:21, Rick van Rein wrote:

> [...] DKIM, SPF and DMARC are of interest to any mail flow.

They sure are. If you browse through mailing list archives of years gone
by, you can find my own messages about list X or Y breaking DKIM, SPF or
both. Also, people have been passionate about Reply-To-Munging long
before RFCs 4408 and 4870 were written. For a blast from the past, you
can start here: http://marc.merlins.org/netrants/listreplyto.html

If you need an example (to name but one), see the Roundcube Users
mailing list, which still adds a footer to the message bodies, thus
breaking DKIM. Very easily prevented by flipping a configuration switch,
alas the list admins don't seem to care.

There is a big difference between leaving existing headers and bodies
intact, like the Postfix mailing list commendably does, and messing with
existing headers or bodies, which breaks DKIM. My own DKIM setup exempts
'Received' headers from signing, but if a list software messes with
anything else, it is likely to break signatures.

As for DMARC, I tested it for several months, and found it lacking.
Beyond being unsuitable for many of today's mailing lists as seen from
the back-and-forth of reports (and thus arguably being broken by
design), I don't think a sender A can say "if DMARC verification on this
message fails, implement policy X" and expect recipients B and C to do
just that. Once a message reaches B and C, they'll do whatever they
please with it. Also, I'd like to earn some money for each bounced DMARC
report, but that's a different matter...

I have tried to find one of Viktors much more in-depth statements on
DMARC, but to no avail.

-Ralph
Reply | Threaded
Open this post in threaded view
|

Re: Lists and spam prevention / use of Reply-To:

Wietse Venema
In reply to this post by Rick van Rein
Rick van Rein:
[ Charset ISO-8859-1 converted... ]

> Hi,
>
> > i noted that it's possible to get dmarc fail on postfix maillist
> >
> > its spf none, dkim none, dmarc fail, in my tests, arc is not tested or
> > planned to be in use
>
>
> I tested your two emails for DKIM, and both failed for me.
> The ones by Noel and Ralph did get through.  I used dkimverify.py
> from the dkimpy package, and copy/paste to get the message source
> in.
>
> A difference between your DKIM-Signature and the others' is that
> you have set c=simple/simple where the others use c=relaxed/relaxed
> and c=relaxed/simple.  As a result of this, you are picking on
> whitespace modifications in the headers while the others are not:

Cut-and-paste modifies whitespace, making your experiment invalid.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: Lists and spam prevention / use of Reply-To:

@lbutlr
In reply to this post by Ralph Seichter
On 29 Aug 2017, at 04:54, Ralph Seichter <[hidden email]> wrote:
> If you need an example (to name but one), see the Roundcube Users
> mailing list, which still adds a footer to the message bodies, thus
> breaking DKIM. Very easily prevented by flipping a configuration switch,
> alas the list admins don't seem to care.

This is a failure of DKIM, not a failure of mailing lists. Mailing lists have been adding footers since the 80s, but when DKIM was developed none of those people cared about making their new thing work with existing models, they just said, "well, yeah, you have to change that."

There are very good reasons for footers on many lists, and DKIM should be smart enough to figure this out.

--
Apple broke AppleScripting signatures in Mail.app, so no random signatures.

Reply | Threaded
Open this post in threaded view
|

Re: Lists and spam prevention / use of Reply-To:

Benny Pedersen-2
@lbutlr skrev den 2017-08-29 13:42:

> There are very good reasons for footers on many lists, and DKIM should
> be smart enough to figure this out.

its solved in arc ?

i still dont know if arc will replace dmarc or not, if maillists stop
breaking dkim, then dmarc and arc is not needed at all

to some extend opendkim have body length limiter, but not tested or
dokumented very well

let me come with a joke now, if we stop verifying dkim to the first mail
signature and just say all under that sig is mailllist forged content we
did not open a can of worms to solve afterwards ?

i think people need to rethink more why breaking dkim is bad

--
forged content testers see here
Reply | Threaded
Open this post in threaded view
|

Re: Lists and spam prevention / use of Reply-To:

@lbutlr
On 29 Aug 2017, at 06:00, Benny Pedersen <[hidden email]> wrote:
> let me come with a joke now, if we stop verifying dkim to the first mail signature and just say all under that sig is mailllist forged content we did not open a can of worms to solve afterwards ?
>
> i think people need to rethink more why breaking dkim is bad

The very phrase "breaking DKIM" is a problem; it is not breaking DKIM, it is a purposeful design failure in DKIM that has *never* worked properly. No one broke it, it was designed to be broken from the start.

--
Apple broke AppleScripting signatures in Mail.app, so no random signatures.

Reply | Threaded
Open this post in threaded view
|

Re: Lists and spam prevention / use of Reply-To:

Ralph Seichter
In reply to this post by @lbutlr
On 29.08.2017 13:42, @lbutlr wrote:

> There are very good reasons for footers on many lists, and DKIM should
> be smart enough to figure this out.

I disagree about "very good reasons for footers on many lists". Meta
information belongs into the message headers, not the body. DKIM-signed
messages are letters, not postcards, and no non-totalitarian postal
service would dare open your letter and scribble junk on the contents.
Stick to the envelope, Mr. Postman. ;-)

As for part two: If someone messes with cryptographically signed content
en route, it is not the signer's fault at all. Alice's responsibility
ended when she hit the send button. Calling for Bob, the recipient of
the messed up message, to figure out why parts were broken by the
transporting third party does not make any sense either. He who messes
is at fault.

I am not saying DKIM is perfect, but it is easy for mailing list admins
to not break signatures -- just leave existing data alone.

-Ralph

P.S.: We're drifting far away from Postfix here.
Reply | Threaded
Open this post in threaded view
|

Re: Lists and spam prevention / use of Reply-To:

Rick van Rein
Hah,

Thanks for the pointers, especially Ralph!

> I disagree about "very good reasons for footers on many lists". Meta
> information belongs into the message headers, not the body.

I've been thinking along those lines too... there could easily be new
header definitions for "Suggested Tagging" and "Discretionary Advice"
that could be rendered in all the lively colours that a Subject header
and (plaintext) message body are lacking.

This won't break a thing in terms of DKIM and DMARC; it doesn't call
for something as complex as ARC.  And even if it's a bit difficult in
Postfix, it's doable and doesn't bring out cryptographic key handling,
or parsing large messages before being able to sign and forward them.

I've been trying to understand ARC's cryptographic design, as I'm not
satisfied with its syntax-and-procedures level description.  I have
the suspicion that it may be over-engineered, but I can't pin that down
yet.

-Rick
Reply | Threaded
Open this post in threaded view
|

Re: Lists and spam prevention / use of Reply-To:

Philip Paeps
In reply to this post by Ralph Seichter
On 2017-08-29 14:12:29 (+0200), Ralph Seichter wrote:
>On 29.08.2017 13:42, @lbutlr wrote:
>>There are very good reasons for footers on many lists, and DKIM should
>>be smart enough to figure this out.
>
>I disagree about "very good reasons for footers on many lists". Meta
>information belongs into the message headers, not the body. DKIM-signed
>messages are letters, not postcards, and no non-totalitarian postal
>service would dare open your letter and scribble junk on the contents.  
>Stick to the envelope, Mr. Postman. ;-)

Scribbling in the body also breaks PGP signatures.  At least that's
trivially worked around by adding the list footer in a separate MIME
part as many lists do.  But DKIM still doesn't like that.

DKIM, SPF and DMARC have one thing in common: they're all hostile to
mailing lists.

>P.S.: We're drifting far away from Postfix here.

Sorry for continuing to drift.  I'll shut up again. :)

Philip

--
Philip Paeps
Senior Reality Engineer
Ministry of Information
Reply | Threaded
Open this post in threaded view
|

Re: Lists and spam prevention / use of Reply-To:

Norton Allen
In reply to this post by Ralph Seichter
On 8/29/2017 8:12 AM, Ralph Seichter wrote:
> I disagree about "very good reasons for footers on many lists". Meta
> information belongs into the message headers, not the body. DKIM-signed
> messages are letters, not postcards, and no non-totalitarian postal
> service would dare open your letter and scribble junk on the contents.
> Stick to the envelope, Mr. Postman.;-)
The problem with sticking all the list meta-information in the headers
is that most users have no idea how to access email headers or parse
them for the salient information. While I believe it is valuable to
allow the originally signed content to pass through without corrupting
the signature, the context of the message being sent to a mailing list
argues for allowing some consistent list context information to be
included where users can see it.
Reply | Threaded
Open this post in threaded view
|

Re: Lists and spam prevention / use of Reply-To:

Benny Pedersen-2
In reply to this post by Philip Paeps
Philip Paeps skrev den 2017-08-29 15:18:

> Scribbling in the body also breaks PGP signatures.  At least that's
> trivially worked around by adding the list footer in a separate MIME
> part as many lists do.  But DKIM still doesn't like that.

imho opendkim can limit body content signing (body length), so if that
is limited, all content after that limit will be ignored on verify, its
just not very used, but its there

> DKIM, SPF and DMARC have one thing in common: they're all hostile to
> mailing lists.

and i still get dmarc pass here, so even if maillists software is over
20 years old it still does not break dkim, funny part is that software
recently trying to solve dkim maillists problems are doing more bad
things then solve it
Reply | Threaded
Open this post in threaded view
|

Re: Lists and spam prevention / use of Reply-To:

Benny Pedersen-2
In reply to this post by Norton Allen
Norton Allen skrev den 2017-08-29 15:43:

> The problem with sticking all the list meta-information in the headers
> is that most users have no idea how to access email headers or parse
> them for the salient information.

squirrelmail have plugin for list-id headers, that plugin is not in
roundcube yet, but roundcube solve it by reply to maillist or all
senders :)

note how many that post to cc adresses, sign of badly software not
handling maillist very well

> While I believe it is valuable to
> allow the originally signed content to pass through without corrupting
> the signature, the context of the message being sent to a mailing list
> argues for allowing some consistent list context information to be
> included where users can see it.

if dkim was designed for mime dkim signing / verify in would it be
better ?

i begin to think it could do some good there, by not need to disable
8bitmime in smtpd stage, i remember this is needed if amavisd dkim signs
mails, in opendkim i have not yet seen if its needed or not, as long i
still get dmarc pass i am happy

to other recipiens fix dkim verify and or dmarc report my mail as dmarc
fail, not my fault unless there is a bug in opendmarc

is postfix pipe content to dkimverify problematic to whitespace loose ?
Reply | Threaded
Open this post in threaded view
|

Re: Lists and spam prevention / use of Reply-To:

Ralph Seichter
In reply to this post by Norton Allen
On 29.08.2017 15:43, Norton Allen wrote:

> The problem with sticking all the list meta-information in the headers
> is that most users have no idea how to access email headers or parse
> them for the salient information.

I see it as a MUA's task to present meta information in a palatable way,
but of course there is no help against the very laziest users, who are a
bane to mailing lists in their own right. But I digress. From the looks
of it, you're using Thunderbird, and given the existing headers

  List-Id: Postfix users <[hidden email]>
  List-Post: <mailto:[hidden email]>
  List-Help: <http://www.postfix.org/lists.html>
  List-Unsubscribe: <mailto:[hidden email]>
  List-Subscribe: <mailto:[hidden email]>

you will be familiar with TB's "Reply List" feature. It would be nice if
vanilla Thunderbird presented other List-* headers in a useful fashion.
https://addons.mozilla.org/en-US/thunderbird/addon/display-mailing-list-header/
seems to have done just that in the past, no idea if there are plugins
available for current TB versions. Thunderbird is still my go-to MUA
because of multi-identity support and the Enigmail extension, but things
could be improved even more.

Not everybody is comfortable examining raw message headers of course,
but to screw up message subjects or bodies just because some MUAs have
bad mailing list support just won't do. I believe that if Joe Random
User wants to use mailing lists, he can be bothered to use suitable
software for this purpose. "I will use software X because I always do,
useless for this purpose or not, and post HTML because I like things
pretty, useless or not" do not strike me as positions we need to
support. ;-)

-Ralph
12