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

[Rick van Rein]

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

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

[Rick van Rein]

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

Re[2]: postfix log in mysql

[Kev]

> You might want to look into something like the Logstash 
> (https://www.elastic.co/products/logstash).  

looks promising! thanks you!

On Mon, 28 Aug 2017 10:11:14 -0600
James Reynolds  wrote:

> You might want to look into something like the Logstash 
> (https://www.elastic.co/products/logstash).  
> 
> James
> 
> > On Aug 27, 2017, at 9:51 PM, Kev  wrote:
> > 
> > Hi postfixers,
> > 
> > We have spam filter servers for our down, 5 of them to be exact. we use
> > amavisd, bitdefender & clamav for spam and virus filter. 
> > 
> > we have a self help portal done in php/mysql for users to manage
> > whitelist/blacklist etc, now i want to allow users to check there email
> > logs to they can find if any wanted email is blocked,
> > 
> > so the question is, how can i log postfix to a mysql db where i can write
> > an interface for users to search for email and see what did the
> > blocking, such as rbl, amavis etc ? 
> > 
> > ive seen some solutions to use syslog in to mysql but i was thinking
> > something much simpler where i will still have logs in place even if
> > mysql fails.
> > 
> > rgds
> > 
> > 

Suggested version for upgrade

[Gabriele Bulfon]

Hi,
I'm using Postfix 2.7.1 for some years now on our systems, built around our 
XStreamOS / illumos distro.
I'm considering to upgrade Postfix to a more recent version.
What is the best upgrade path I should choose?
Should I really consider to upgrade directly to latest (3.2.2) or maybe start 
by upgrading to 2.11.x?
What is my best option, keeping all my current configuration files untouched as 
a start?
Thanks for any help!
Gabriele
Sonicle S.r.l.
:
http://www.sonicle.com
Music:
http://www.gabrielebulfon.com
Quantum Mechanics :
http://www.cdbaby.com/cd/gabrielebulfon

Re: postfix log in mysql

[joao reis]

I save correlated logs from postfix (and milter daemons) in mongodb.

https://www.balabit.com/documents/syslog-ng-ose-latest-guides/en/syslog-ng-ose-guide-admin/html/configuring-destinations-mongodb.html
https://www.balabit.com/documents/syslog-ng-ose-latest-guides/en/syslog-ng-ose-guide-admin/html/configuring-pattern-databases.html

In one registry I can get all information about delivery that I need and 
nothing more:


{
"_id" : ObjectId("5991fbb0c2544d511c3a5290"),
"TO" : "xxx...@domain.com",
"SUBJECT" : 
"KEdSVVBPIE1QRSkgQXJxdWl2byBkZSBSZW1lc3NhIGRvIGRpYTogMTAvMDgvMjAxNw==",

"STATUS_AT" : ISODate("2017-08-14T19:36:16.000Z"),
"STATUS" : "sent",
"SIZE" : 2918,
"SERVER" : "submitter31.zyx.net",
"SASLAUTH" : "a...@o62.xyz.net",
"RETURNPATH" : "sup...@xyz.com",
"RELAY_IP" : "168.0.0.0",
"RELAY_HOST" : "relay..com.br",
"REASON" : "(250 OK id=1dhLEB-03037zm-MD)",
"QUEUEID_CUST" : "None",
"QUEUEID" : "024D781B27AC",
"FROM" : "sup...@xyz.com",
"DSN" : "2.0.0",
"DELAY" : "8.6",
"CLIENTIP" : "177.7.7.7",
"BEGIN_AT" : ISODate("2017-08-14T19:36:08.000Z")
}

much cleaner and simpler than logstash, either rsyslog and syslog-ng 
clients connect to the log server without any other external software 
and it is working very well.


Joao Reis.


On 08/29/2017 05:51 AM, Kev wrote:

You might want to look into something like the Logstash 
(https://www.elastic.co/products/logstash).

looks promising! thanks you!

On Mon, 28 Aug 2017 10:11:14 -0600
James Reynolds  wrote:


You might want to look into something like the Logstash 
(https://www.elastic.co/products/logstash).

James


On Aug 27, 2017, at 9:51 PM, Kev  wrote:

Hi postfixers,

We have spam filter servers for our down, 5 of them to be exact. we use
amavisd, bitdefender & clamav for spam and virus filter.

we have a self help portal done in php/mysql for users to manage
whitelist/blacklist etc, now i want to allow users to check there email
logs to they can find if any wanted email is blocked,

so the question is, how can i log postfix to a mysql db where i can write
an interface for users to search for email and see what did the
blocking, such as rbl, amavis etc ?

ive seen some solutions to use syslog in to mysql but i was thinking
something much simpler where i will still have logs in place even if
mysql fails.

rgds

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

[Ralph Seichter]

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

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

[Wietse Venema]

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

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

[@lbutlr]

On 29 Aug 2017, at 04:54, Ralph Seichter  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.

Re: showing an recipient that doesn't receive the mail

[Nils Weidinger]

Thank you all. It's working fine. Kind regards.

Am 28.08.2017 um 18:47 schrieb Darek M.:
An MTA only looks at the envelope To for routing.  You can put 
anything you want in the message To header, so you could rewrite it 
any way you need to.



On 8/28/2017 12:04 PM, Nils wrote:

Hi,

    when composing an email, can I assign the header value "To" in a 
way that it is shown by the email client but ignored by postfix?


    I've created a php-cronjob for a customer, that fetches mails 
from an imap box (mta is postfix), recomposes them and forwards them 
to a list of recipients. Mostly like a mailing list would do. Now the 
customer doesn't want the final recipients to see their own addresses 
in the to-field. Instead he wants the from- and the to-field of the 
mail to seem unchanged. How can I do that without looping?


Is this even possible without touching the postfix configuration? If 
not, how would I configure postfix to make this possible?


Kind regards, Nils




--


18 Jahre - ganz einfach

---
Scheltwort IT-Services KG
Motzstr. 1
D-34117 Kassel
Handelsregister: HRA 9854, Amtsgericht Kassel

Komplementär: Gerd Scheltwort

Tel. +49.561.789479-0
Fax +49.561.789479-99
E-Mail w...@scheltwort-its.de
Internet www.scheltwort-its.de
---

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

[Benny Pedersen]

@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

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

[@lbutlr]

On 29 Aug 2017, at 06:00, Benny Pedersen  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.

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

[Ralph Seichter]

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.

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

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

[Philip Paeps]

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

Feature request: References header in postfix bounce messages

[IB Development Team]

Hi,

Please consider adding option for including References header in postfix
bounce messages.

Sender app (i.e. ticket processing suff like OTRS) will be happy to use
it to automatically merge bounce message to the same thread as original
message which may save time in bigger setups.

Similar request:

https://bugs.launchpad.net/ubuntu/+source/postfix/+bug/1575207

-- 
Regards,
Pawel Boguslawski

IB Development Team
https://dev.ib.pl/

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

[Norton Allen]

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.

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

[Benny Pedersen]

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

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

[Benny Pedersen]

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 ?

Re: Suggested version for upgrade

[Noel Jones]

On 8/29/2017 3:58 AM, Gabriele Bulfon wrote:
> Hi,
> 
> I'm using Postfix 2.7.1 for some years now on our systems, built
> around our XStreamOS / illumos distro.
> 
> I'm considering to upgrade Postfix to a more recent version.
> What is the best upgrade path I should choose?
> Should I really consider to upgrade directly to latest (3.2.2) or
> maybe start by upgrading to 2.11.x?
> What is my best option, keeping all my current configuration files
> untouched as a start?
> 

The canonical answer is to read the docs.  ;)

It should be safe to upgrade directly to the latest version. Using
the latest version will give you the best support and all the
current features. Postfix goes to great lengths to not break
existing installations when you upgrade, but you should read *all*
the release notes to see if any of the special cases apply to you.


  -- Noel Jones

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

[Ralph Seichter]

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 
  List-Post: 
  List-Help: 
  List-Unsubscribe: 
  List-Subscribe: 

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

Re: postfix/postqueue[5742]: panic: vbuf_print: output for \%s\ exceeds space 0

[A. Schulze]

wietse:


OK, now please (install and) use ltrace. This provides more details
what happens in postqueue itself (strace gives insight into system
calls, i.e.  the postqueue-kernel interface).


off-list...

I installed ltrace.
I modified pfqgrep: $mailq = "/usr/bin/ltrace /usr/sbin/postqueue -p |";

# pfqgrep -r '+123456789012' > /tmp/ltrace.txt 2>&1
available at https://postmaster.datev.de/tmp/ltrace.txt

There are two strings looking like a queueid in this trace:
3xhXFj2Wt7z4FL3* and 3xhXDS3PqBz4FK9*

that are two messages in the active queue just in the moment I run the  
command above.

postfix delivered both messages as usual...

Btw: as I said, I fixed the initial problem by calling "qshape -w 100"
Is 100 safe? Or even 1000?

I'm fine if you say "Oh ... Andreas run old perl ..." without further  
investigation.

Otherwise I'm willing to support you wherever possible :-)

Andreas

Re: postfix/postqueue[5742]: panic: vbuf_print: output for \%s\ exceeds space 0

[A. Schulze]

A. Schulze:


off-list...

ok not "off list", my fault :-)

Re: Suggested version for upgrade

[Viktor Dukhovni]

On Tue, Aug 29, 2017 at 10:58:08AM +0200, Gabriele Bulfon wrote:

> I'm using Postfix 2.7.1 for some years now on our systems, built around our 
> XStreamOS / illumos distro.
> I'm considering to upgrade Postfix to a more recent version.
> What is the best upgrade path I should choose?

See: 

https://github.com/vdukhovni/postfix/blob/master/postfix/RELEASE_NOTES-2.8
https://github.com/vdukhovni/postfix/blob/master/postfix/RELEASE_NOTES-2.9
https://github.com/vdukhovni/postfix/blob/master/postfix/RELEASE_NOTES-2.10
https://github.com/vdukhovni/postfix/blob/master/postfix/RELEASE_NOTES-2.11
https://github.com/vdukhovni/postfix/blob/master/postfix/RELEASE_NOTES-3.0
https://github.com/vdukhovni/postfix/blob/master/postfix/RELEASE_NOTES-3.1
https://github.com/vdukhovni/postfix/blob/master/postfix/RELEASE_NOTES-3.2

> Should I really consider to upgrade directly to latest (3.2.2) or maybe start
> by upgrading to 2.11.x?

The 3.0 release mostly only affects distribution maintainers as
the build and packaging details change in support of shared libraries
and dynamically loadable maps.  Otherwise, user-visible changes are
minor, and backwards incompatible changes are subject to the
"compatibility_level" setting.  See the release notes.

Therefore, I would not suggest stopping at 2.11, but only you can
determine whether some changes in a later release are unexpectedly
a problem for you.  As much as possible, Postfix remains backwards
compatible.

-- 
Viktor.

RHS item separators in alias and virtual lists: comma or space okay?

[Tom Browder]

It's clear that list items in main.cf can be comma or space separated. Is
that also true for alias and virtual lists?

Thanks.

-Tom

Re: postfix/postqueue[5742]: panic: vbuf_print: output for \%s\ exceeds space 0

[Wietse Venema]

A. Schulze:
> There are two strings looking like a queueid in this trace:
> 3xhXFj2Wt7z4FL3* and 3xhXDS3PqBz4FK9*
> 
> that are two messages in the active queue just in the moment I run the  
> command above.
> postfix delivered both messages as usual...

To clarify, this panic call happens with arbitrary messages in the
mail queue, not just one message?  In that case I suspect a
site-specific problem, like, a bad build of some kind.

I'm a little surprised that ltrace does not show calls into the
Postfix library. Is this Postfix from a distribution or a custom
build? If it is the latter that would open up the ppssibility of a
site-specific problem.

Wiete

Re: RHS item separators in alias and virtual lists: comma or space okay?

[Benny Pedersen]

Tom Browder skrev den 2017-08-29 18:36:

It's clear that list items in main.cf [1] can be comma or space
separated. Is that also true for alias and virtual lists?


simple question, simple answer

postconf -nf
postconf -Mf

this can be used to create new configs with, just remember backup old 
ones

Re: RHS item separators in alias and virtual lists: comma or space okay?

[Wietse Venema]

Tom Browder:
> It's clear that list items in main.cf can be comma or space separated. Is
> that also true for alias and virtual lists?

What is an alias or virtual list?

Wietse

Re: RHS item separators in alias and virtual lists: comma or space okay?

[Tom Browder]

On Tue, Aug 29, 2017 at 15:46 Wietse Venema  wrote:

> Tom Browder:
> > It's clear that list items in main.cf can be comma or space separated.
> Is
> > that also true for alias and virtual lists?
>
> What is an alias or virtual list?


I mean the RHS of aliases, e.g., as in simple mailing lists in the alias
file:

needles:
  j...@examp.com
  bu...@foo.com



>
> Wietse
>

Re: RHS item separators in alias and virtual lists: comma or space okay?

[Tom Browder]

On Tue, Aug 29, 2017 at 16:10 Tom Browder  wrote:

> On Tue, Aug 29, 2017 at 15:46 Wietse Venema  wrote:
>
>> Tom Browder:
>> > It's clear that list items in main.cf can be comma or space separated.
>> Is
>> > that also true for alias and virtual lists?
>>
>> What is an alias or virtual list?
>
>
> I mean the RHS of aliases, e.g., as in simple mailing lists in the alias
> file:
>
> needles:
>   j...@examp.com
>   bu...@foo.com
>

It seems to work so I guess spaces instead of commas are ok.

Thanks.

-Tom

Re: RHS item separators in alias and virtual lists: comma or space okay?

[Benny Pedersen]

Tom Browder skrev den 2017-08-29 23:11:


needles:
j...@examp.com
bu...@foo.com


It seems to work so I guess spaces instead of commas are ok.


to test it:

postmap -q needless maptype:mapfile

postmap -q needless hash:/etc/mail/aliases

mitigating gmail spam traps: how does one add the required headers?8

[Tom Browder]

Gmail has a list of steps recommended to minimize spam identification,
particularly mail sent as bulk mail (as from mailing lists).

One of the recommendations is to use DKIM and that is clearly explained on
the postfix website.

The other steps are fairly straight forward, also, but how does one add the
various headers they recommend?  I assume it's via a filter, but which one
and how is it done?

Thanks.

-Tom

Re: mitigating gmail spam traps: how does one add the required headers?8

[Gary]

It would help to have a link to Gmail's suggestions.

This website tests dkim and spf. 
http://dkimvalidator.com



  Original Message  
From: tom.brow...@gmail.com
Sent: August 29, 2017 4:10 PM
To: postfix-users@postfix.org
Subject: mitigating gmail spam traps: how does one add the required headers?8

Gmail has a list of steps recommended to minimize spam identification, 
particularly mail sent as bulk mail (as from mailing lists).

One of the recommendations is to use DKIM and that is clearly explained on the 
postfix website.

The other steps are fairly straight forward, also, but how does one add the 
various headers they recommend?  I assume it's via a filter, but which one and 
how is it done?

Thanks.

-Tom

Re: RHS item separators in alias and virtual lists: comma or space okay?

[Wietse Venema]

Tom Browder:
> On Tue, Aug 29, 2017 at 15:46 Wietse Venema  wrote:
> 
> > Tom Browder:
> > > It's clear that list items in main.cf can be comma or space separated.
> > Is
> > > that also true for alias and virtual lists?
> >
> > What is an alias or virtual list?
> 
> 
> I mean the RHS of aliases, e.g., as in simple mailing lists in the alias
> file:
> 
> needles:
>   j...@examp.com
>   bu...@foo.com

Email addresses must be separated with commas. That is not a Postfix
requirement, but a requirement that follows from email address syntax.

Wietse

Re: RHS item separators in alias and virtual lists: comma or space okay?

[Viktor Dukhovni]

On Tue, Aug 29, 2017 at 09:10:26PM +, Tom Browder wrote:

> On Tue, Aug 29, 2017 at 15:46 Wietse Venema  wrote:
> 
> > Tom Browder:
> > > It's clear that list items in main.cf can be comma or space separated.
> > Is
> > > that also true for alias and virtual lists?
> >
> > What is an alias or virtual list?
> 
> 
> I mean the RHS of aliases, e.g., as in simple mailing lists in the alias
> file:
> 
> needles:
>   j...@examp.com
>   bu...@foo.com

Use commas, that's the separator in lists of email addresses in
RFC2822 headers, and is also used by the Postfix *SQL and LDAP
drivers to translate multiple results into a list of addresses.

You can add spaces after commas for readability, you can also
fold lines, which makes "diffs" easier to read.

aliases:  
users: moe, larry, curly

virtual:
us...@example.com
m...@example.com,
la...@example.com,
cu...@example.com

-- 
Viktor.

Re: RHS item separators in alias and virtual lists: comma or space okay?

[Tom Browder]

On Tue, Aug 29, 2017 at 6:28 PM, Wietse Venema  wrote:
> Tom Browder:
>> On Tue, Aug 29, 2017 at 15:46 Wietse Venema  wrote:
>> > What is an alias or virtual list?
>>
>> I mean the RHS of aliases, e.g., as in simple mailing lists in the alias
>> file:
>>
>> needles:
>>   j...@examp.com
>>   bu...@foo.com
>
> Email addresses must be separated with commas. That is not a Postfix
> requirement, but a requirement that follows from email address syntax.

Ah, okay, thanks!

-Tom

Re: mitigating gmail spam traps: how does one add the required headers?8

[Tom Browder]

On Tue, Aug 29, 2017 at 6:17 PM, Gary  wrote:
> It would help to have a link to Gmail's suggestions.

Good idea, Gary.  Here it is:

  https://support.google.com/mail/answer/81126?hl=en

-Tom

Re: RHS item separators in alias and virtual lists: comma or space okay?

[Tom Browder]

On Tue, Aug 29, 2017 at 6:33 PM, Viktor Dukhovni
 wrote:
> On Tue, Aug 29, 2017 at 09:10:26PM +, Tom Browder wrote:
>> > Tom Browder:
>> > > It's clear that list items in main.cf can be comma or space separated.
>> > Is
>> > > that also true for alias and virtual lists?
...
>> I mean the RHS of aliases, e.g., as in simple mailing lists in the alias
>> needles:
>>   j...@examp.com
>>   bu...@foo.com
...
> Use commas, that's the separator in lists of email addresses in
> RFC2822 headers, and is also used by the Postfix *SQL and LDAP
> drivers to translate multiple results into a list of addresses.
>
> You can add spaces after commas for readability, you can also
> fold lines, which makes "diffs" easier to read.
>
> aliases:
> users: moe, larry, curly
>
> virtual:
> us...@example.com
> m...@example.com,
> la...@example.com,
> cu...@example.com

Thanks, Viktor.

-Tom

Re: [SPAM?] Re: Lists and spam prevention / use of Reply-To:

[Richard Damon]

On 8/29/17 8:12 AM, 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. ;-)

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.

I suggest you then talk the the legislators in the jurisdictions that 
MANDATE that many mailing list have clearly visible unsubscribe 
instructions. I suppose their alternative would be to try to mandate 
that all email software processes the defined meta-data to present the 
instructions to the user. (I have seen legal opinions that the List- 
headers do not meet the requirements of some email regulations)


I suppose also it would be considered inappropriate to put said sealed 
envelope on a community builtin board, or arrive at a newspaper with a 
stack of sealed envelopes and tell them you have an editorial reply that 
you want them to add to the paper for that day.


Sending signed content to a system that is known to need to adjust it is 
unsocial. Try to send a letter wrapped in clear plastic (with the stamp 
inside), if they notice I bet the wrapping will be removed or the letter 
returned.


Remember, many mailing list are different than just a simple mail 
delivery system. Yes, I would expect that a simple MTA, whose job it is 
to just deliver the mail as directed, to not need to get 'into' the message.


--
Richard Damon