[pfx] Re: postfix repo

[Marvin Renich via Postfix-users]

* Peter via Postfix-users  [240117 04:57]:
> On 16/01/24 17:26, Scott Kitterman via Postfix-users wrote:
> 
> same work?  At any rate, it's really up to someone in the Debian community
> to step up and do that, and I'm not trying to volunteer you for the job, it

Scott is an official Debian Developer, and has done most of the
(official Debian) postfix package uploads since 2016.  I mistakenly
thought he was the maintainer of record, but that appears to be LaMont
Jones.  Thank you also, LaMont!

So, Scott is already one of the volunteers doing this, and he does a
remarkable job of keeping both stable and unstable packages in sync with
the official Postfix sources.

...Marvin

___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: postfix repo

[Marvin Renich via Postfix-users]

Many thanks, Scott, for keeping the official Debian postfix packages
up-to-date.  It is very much appreciated by me and, I am sure, by many
others.

...Marvin

___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: smtp auth on port 25

[Marvin Renich via Postfix-users]

* Benny Pedersen via Postfix-users  [230815 05:10]:
> Peter via Postfix-users skrev den 2023-08-15 10:44:
> 
> > This is a bad idea for several reasons.  If you want submission use
> > ports 465 and/or 587 as they are intended.  Don't try to use a service
> > that is meant for a different purpose for this.
> 
> mta to mta can use port 465 or 587 aswell for intended purpose :)

MTA to MTA on submission port is _not_ the intended purpose!  It can
only be _misused_ for this purpose if the submission port is poorly
configured.  Auth should be _required_ on these ports, which precludes
MTA to MTA using these ports.

> so its valid if both client and server is maintained from same admin, but
> not if its another maintainer, ihmo this is the diffrent

You shouldn't do this.

...Marvin

___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Please remove mailing list tag

[Marvin Renich via Postfix-users]

* Phil Stracchino via Postfix-users  [230315 11:11]:
> On 3/15/23 10:36, Marvin Renich via Postfix-users wrote:
> > That technical issue aside, in this thread there have been two posters
> > who expressed a desire to keep the tags, one said get rid of it in
> > users, but keep it in announce (I don't understand his reasoning, I am
> > just reporting his stated preference),
> 
> 
> Because if you're filtering all Postfix list traffic into the same folder,
> you probably want announcements to stand out at a glance.  They may be of
> immediate importance.

Thanks for clarifying, Phil.  I can see that, and since it is a
low-volume list, I would not find it to be particularly bothersome.

...Marvin

___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Please remove mailing list tag (was Re: The joke writes itself.)

[Marvin Renich via Postfix-users]

* Matthias Andree via Postfix-users  [230311 10:48]:
> Am 10.03.23 um 17:12 schrieb Marvin Renich via Postfix-users:
> > Additionally, every MUA that I know of recognizes a subject beginning
> > with "Re:" or "RE:" and when replying avoids duplicating this in the
> > reply subject.
> > 
> > While I have used mutt exclusively for a long time to send email, I
> > occasionally use other programs for reading.  I just checked both
> > Thunderbird and Evolution (and mutt), and none of them recognize
> > "[prefix] Re:", so unless the person replying realizes it and manually
> > adjusts the subject, the subject will keep growing with each reply.
> > 
> > I have not heard of any MUA that recognizes "[prefix] Re:", but that
> > doesn't mean there aren't any.
> > 
> > Please, please, _please_ remove the subject prefix.
> 
> I don't know about Mailman 3 because it seems like an underfeatured
> rewrite (someone tell me if it learned all Mailman 2 features AND has a
> sound migration path including stable archive URLs shipping in the
> defualt install and not requiring holey scripting languages) - but the
> list drivers should strip duplicate Re: [prefix] tags.
> 
> What you, Marvin, have seen is probably something on your sending end,
> or the old and the new Subject prefix mixed. Or else please point me to
> a message-ID of a mail send through the new list driver that has "[pfx]
> Re: [pfx] Re:" or similar messups. I don't see such in my Thunderbird
> view of what I received through the mailing list, except some "[pfx] Re:
> [P-U] Re:" on this very thread, which will stop once people stop keeping
> the [P-U], or in case there's a filter installed that weeds out the
> [P-U] from the Subject:s.

That mostly alleviates my technical objection, though it doesn't fix the
problem for cross-posting (which is usually bad, but there are occasions
where it is appropriate) or for off-list replies.

That technical issue aside, in this thread there have been two posters
who expressed a desire to keep the tags, one said get rid of it in
users, but keep it in announce (I don't understand his reasoning, I am
just reporting his stated preference), and six said they would like to
remove the tags (one of those appears to be the person at sys4.de
responsible for the list).  And I didn't count Viktor who wanted the tag
to take as little space as possible and "was also quite happy with no
tags".

The tags only provide any benefit at all if you read several mailing
lists from the same inbox.  Most people reading technical mailing lists
have a sorting mechanism in place, either with something like procmail
or maildrop, or with filters in their MUA.  In those cases, the tags are
not only redundant and provide no benefit, but they have a negative
impact on readability and length of subject line.

To whomever has the authority to change this (is that you, Wietse?),
please reconsider and remove the tags.

Thanks...Marvin

___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: The joke writes itself.

[Marvin Renich via Postfix-users]

* Cooper, Robert A via Postfix-users  [230310 09:59]:
> I posted about the List-ID changing three days ago, but it seems to
> have gotten lost in the prefix discussion.  for the record, I like
> list prefixes. It's easier to filter on subject than on headers that
> may or may not be present from any particular list.
> 
> I've found one change to the mailing list header I didn't expect, and
> my mail filter for the list 'broke' on it.

It seems you like them for purposes having to do with automation, rather
than that they help you read the messages.  This is clearly a job for
the List-Id header.  The fact that it broke once when a major change was
being made to the mailing list is not a reason to prefer subject
filtering over list-id filtering; your filter would have broken if the
[P-U] prefix had been in use for a while and then it was changed to
[pfx].  It is no different.  The list-id is intended to remain constant,
if not for the life of the list, at least it should only change when
major changes are necessary anyway.

> The old server had:
> List-Id: Postfix users 
> 
> The new one has:
> List-Id: "For discussions about using Postfix: questions, problem reports,
> or feature requests. Open subscription, unmoderated,
> posting by members only." 
> 
> (and yes, the new list-id actually has postfix-users.postfix.org, instead of 
> @.)

This may have been an intentional change to conform to RFC 2919 for
List-Id:

  The list identifier will, in most cases, appear like a host name in a
  domain of the list owner.

> RobertC

Additionally, every MUA that I know of recognizes a subject beginning
with "Re:" or "RE:" and when replying avoids duplicating this in the
reply subject.

While I have used mutt exclusively for a long time to send email, I
occasionally use other programs for reading.  I just checked both
Thunderbird and Evolution (and mutt), and none of them recognize
"[prefix] Re:", so unless the person replying realizes it and manually
adjusts the subject, the subject will keep growing with each reply.

I have not heard of any MUA that recognizes "[prefix] Re:", but that
doesn't mean there aren't any.

Please, please, _please_ remove the subject prefix.

...Marvin

___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: The joke writes itself.

[Marvin Renich via Postfix-users]

* Mal via Postfix-users  [230310 03:23]:
> 
> 
> On 10/03/2023 5:24 pm, Viktor Dukhovni via Postfix-users wrote:
> > I was also quite happy with
> > no tags at all.
> 
> +1 no tags

I wholeheartedly agree.  The subject tag hinders, rather than helps,
reading list mail.  The List-Id provides better functionality than
subject tags.

And while we're at it, all that extra text in the List-Id is just too
much.  Can you please shorten it so that the entire header fits in 72
characters?  Perhaps something like

List-Id: "http://www.postfix.org/lists.html; 

...Marvin

___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

Re: Controlling maildir sub-folder delivery?

[Marvin Renich]

* Bill Cole  [210504 15:12]:
> On 2021-05-04 at 14:55:29 UTC-0400 (Tue, 04 May 2021 14:55:29 -0400)
>  
> is rumored to have said:
> 
> > Using Linux, postfix, dovecot.
> > 
> > For sorting incoming mail into different maildir folders, i know general
> > advice is to have postfix deliver to dovecot instead of maildir, and use
> > dovecot sieve to deliver the mail into a user's sub-folder.
> > 
> > Is there anyway within postfix (or policy service) to deliver to a
> > user's maildir sub-folder (based on from address) without relying on
> > dovecot?
> 
> Postfix only knows how to deliver to the top level of a Maildir directory
> (i.e. a properly named file in ~/Maildir/new/, if home_mailbox=Maildir/) and
> does not have any knowledge of how the IMAP mailboxes might be laid out,
> which can vary substantially.
> 
> An alternative to using the Dovecot LDA or LMTP is an old, reliable,
> unmaintained, and probably full of security holes tool: procmail.

I use maildrop, which is part of Courier and appears to be actively
developed and maintained.  I think it is a better replacement for
procmail (though not a drop-in replacement; the filter language is
different).

...Marvin

Re: lightweight/milter Spamassassin-integtration options for Postfix -- current experience / faves?

[Marvin Renich]

* PGNet Dev  [200608 19:19]:
>https://savannah.nongnu.org/projects/spamass-milt/
>https://github.com/mpaperno/spampd
>https://gitlab.com/glts/spamassassin-milter
> 
> anyone have any current experience with any of these?

I also use the first one (Debian package spamass-milter) along with
milter-greylist (only greylisting messages with a spam score in the
lower end of the "positive" range to avoid rejecting false
positives from spamassassin while not greylisting clearly legitimate
email).

...Marvin

Re: Preferred/maintained greylisting options?

[Marvin Renich]

* Laura Smith  [200524 16:00]:
> > I’ve been sort of opposed to greylisting in the past due to a
> > userbase that’s sensitive to delays, but… the spam is worse.
> 
> IMHO Greylisting is rather pointless. Its a blunt tool, and not only
> that it does that unforgivable thing of annoying genuine people.

I agree that greylisting, as most documentation, blogs, etc, describe
how to configure it, has always been a bad idea, primarily because it
delays most or all mail that is not whitelisted.

However, when I first set up greylisting on my family email server (it
was exim way back then, but has long been postfix), I set it up so that
all incoming mail was sent through spamassassin _during_ SMTP, prior to
accept or reject.  Mail with a high enough spam score was rejected
outright.  I then used greylisting _only_ for email whose spamassassin
score was considered spam, but not high enough to reject outright.

This setup virtually eliminates false positives from spamassassin, and
avoids delaying legitimate email except for the few that would have been
rejected falsely.

Contrary to someone else's experience related in this thread, I still
see a significant amount of spam that greylisting blocks, and extremely
few spammers retry and get through.

I have only had one known case (i.e. someone said they were expecting an
email that they didn't receive) in a very long time where a legitimate
email was greylisted and the sending server did not retry, and that was
recently from an outlook365 server.  Ironically, someone was following
Microsoft's instructions to have an IP address removed from outlook365's
internal RBL, and the message sent by Microsoft failed several of
spamassassin's default tests (way to go, Microsoft!) and their server
never retried (I watched the logs and they did not retry from a
different IP address).  What a well-run mail system,
Microsoft.

...Marvin

Re: postsuper manpage: message expiration

[Marvin Renich]

* Wietse Venema  [200119 17:54]:
> Marvin Renich:
> > Postsuper isn't overflowing with options; perhaps a more flexible and
> > simpler design would be to have -e expire and -E expire and release from
> > hold (if it is held).
> 
> Yes, the idea of a third option came to mind.
> 
> > The only con I see to this is "feature creep", which is minimal at this
> > point.  It only becomes an issue when postsuper starts getting more and
> > more options.
> 
> There is a limit to what postsuper can do, because by design it has
> no dependencies on a running Postfix system.

I'm a little confused.  Doesn't postsuper already have -H?  If you add
-e, what is hard about having -E set the flag, and then effectively act
like the user also specified -H with the same queue_id?

...Marvin

Re: postsuper manpage: message expiration

[Marvin Renich]

* Wietse Venema  [200119 08:04]:
> A radically different approach would be to introduce a new 'expired'
> queue and move messages there when they need to be expired, and to
> introduce a new postqueue flag to flush the expired queue (the queue
> manager should not normally scan the expired queue because that
> would slow down all deliveries).
> 
> Pro: Less complexity. No 'expired' state inside queue files.
> 
> Con: More complexity. When expired mail needs to be deferred because
> the bounce daemon is failing, it should go back to the expired
> queue, not to the deferred queue.

Postsuper isn't overflowing with options; perhaps a more flexible and
simpler design would be to have -e expire and -E expire and release from
hold (if it is held).

The only con I see to this is "feature creep", which is minimal at this
point.  It only becomes an issue when postsuper starts getting more and
more options.

...Marvin

Re: Avoidance of duplicate mails reg

[Marvin Renich]

* an...@ursc.gov.in  [191031 09:00]:
> > > We have migrated to a new domain yyy.com.  We also continue to receive
> > > mails on old domain xxx.com.
> > > 
> > > When a sender sends a mail to a...@xxx.com (old domain), mail is
> > > received and delivered to user abcd.  Abcd when he replies to all (his
> > > from email address will be a...@yyy.com [new domain], and hence, mail
> > > is also sent to a...@xxx.com [old domain].  So, the sent mail is also
> > > received back to the same sender.
> > > 
> > > When the actual recipient receives the mail, he will have a...@xxx.com
> > > and a...@yyy.com in the address list. So, when he replies to that
> > > mail, 2 mails will be sent to the same user.
> > > 
> > > What's the best way that, the user receives only one mail, when both
> > > domains are in To addresses?
> 
> Sorry for the trouble.  But, after doing that, when I sent a mail from
> outside to both these email addresses abcd@old.example and
> abcd@new.example (in a single mail) , 2 emails came instead of one.  I
> want that, if both these domains are listed in the same mail, only one
> mail should be received.

The problem here is not Postfix, it is the mail user agent and the
(carbon-based) mail user.

Users of yyy.com, when replying to mail that was sent to their xxx.com
address, must ensure that the reply does not include their old xxx.com
address in the From, To, or CC list.

For those few who still use a command-line mail client, mutt (and
neomutt) can handle this for them, when properly configured.  I have no
clue how to get other MUAs, such as Thunderbird, or (ugh!) Gmail, to do
that automatically, or if they even can.

In the absence of a MUA that is not, or cannot be, configured to do it
automatically, it is the user's responsibility to adjust the recipient
lists appropriately.

...Marvin

Re: Name service error for name=* type=AAAA, when it should be IPv4

[Marvin Renich]

* Bastian Blank <bastian+postfix-users=postfix@waldi.eu.org> [170322 16:27]:
> On Wed, Mar 22, 2017 at 04:11:19PM -0400, Marvin Renich wrote:
> > At 12:30 I edited main.cf to add inet_protocols = ipv4, then restarted
> > Postfix.  I did not reboot or restart any other services, or (knowingly)
> > clear any dns cache.
> 
> - You have by any chance a nameserver != 127.0.0.1 or ::1 in
>   /etc/resolv.conf and it can change during the runtime of the system?
> - You run Postfix daemons chrooted? (check the chroot column in
>   /etc/postfix/master.cf)

Yes to both!  I think that explains it.  resolv.con was copied to the
chroot during a reboot after a power (and therefore network) outage,
when it had a bad value.  The chrooted copy was never updated after the
network came back up.  (The laptop boots much faster than the machine
with the DHCP server!)

Thank you very much!  Now I know how to handle this the next time it
happens (and, in fact, will be expecting it to happen in those
circumstances).

...Marvin

Re: Name service error for name=* type=AAAA, when it should be IPv4

[Marvin Renich]

* Bastian Blank <bastian+postfix-users=postfix@waldi.eu.org> [170322 15:09]:
> Moin
> 
> On Wed, Mar 22, 2017 at 01:04:36PM -0400, Marvin Renich wrote:
> > Mar 21 14:42:45 basil postfix/smtp[12587]: 3AF35240229: 
> > to=<recipie...@host2.example2.com>, relay=none, delay=0.47, 
> > delays=0.25/0.22/0/0, dsn=4.4.3, status=deferred (Host or domain name not 
> > found. Name service error for name=florina.renich.org type=: Host not 
> > found, try again)
> 
> I looked that error up and I'm not sure if I found everything.
> 
> - "Host not found, try again" is TRY_AGAIN, according to
>   src/dns/dns_strerror.c.
> - This error is only produced if res_send produced an error, or if the
>   lookup explicitely gets a SERVFAIL.
> 
> So this message should only show up if something is already pretty wrong
> with DNS.  If there is no network it will show up for example.

Thanks for looking at this, Bastian.  Is there any reason you can think
of that res_send would fail for Postfix, but other programs, such as
host, would get a correct response?  For example, if Postfix calls
res_init, which gets a bad value from resolv.conf, like for a temporary
network outage, then Postfix continues to run for days, not requiring
any dns services.  Meanwhile, the temporary outage is short-lived, but
Postfix never gets the word.  Other programs work, but Postfix continues
to get dns failures because res_init was called at a time when
resolv.conf was bad?

...Marvin

Re: Name service error for name=* type=AAAA, when it should be IPv4

[Marvin Renich]

* Noel Jones <njo...@megan.vbhcs.org> [170322 14:38]:
> On 3/22/2017 1:08 PM, Marvin Renich wrote:
> > Thanks, Wietse and Noel.  Once the IPv4 delivery fails for some reason,
> > and Postfix tries IPv6 (which must fail for this relayhost), the message
> > is deferred.  Do subsequent redelivery attempts only try IPv6?  This is
> > what it looked like was happening, even if the failure was caused by
> > something else.
> 
> Each subsequent attempt will try both, but only the last error is
> reported in the queue listing.

That is what I expected.

> > The message sat in the deferred queue overnight, with more than a dozen
> > redelivery attempts, all with the same result, even though during that
> > time I was able to correctly resolve the relayhost's IP.  postqueue -f
> > failed, but changing inet_protocols to ipv4 and restarting Postfix
> > delivered the message immediately.
> 
> If DNS lookups were working, the temporary delivery error was
> probably something other than a DNS lookup failure.  You should be
> able to find these other delivery attempts logged by the smtp
> delivery process.

The mail.log file contains no other intervening messages.  zgrep smtp
/var/log/* reveals nothing else of any interest.  Except for the [snip]
in the middle, the following is the complete mail.log from message
pickup through delivery of my initial message in this thread.

Mar 21 14:42:45 basil postfix/pickup[11818]: 3AF35240229: uid=1001 
from=<m...@renich.org>
Mar 21 14:42:45 basil postfix/cleanup[12584]: 3AF35240229: 
message-id=<20170321184244.cxyiq2u6w53qt...@basil.wdw>
Mar 21 14:42:45 basil postfix/qmgr[3804]: 3AF35240229: from=<m...@renich.org>, 
size=8480, nrcpt=2 (queue active)
Mar 21 14:42:45 basil postfix/smtp[12587]: 3AF35240229: 
to=<recipie...@host2.example2.com>, relay=none, delay=0.47, 
delays=0.25/0.22/0/0, dsn=4.4.3, status=deferred (Host or domain name not 
found. Name service error for name=florina.renich.org type=: Host not 
found, try again)
Mar 21 14:42:45 basil postfix/smtp[12587]: 3AF35240229: to=<m...@renich.org>, 
relay=none, delay=0.47, delays=0.25/0.22/0/0, dsn=4.4.3, status=deferred (Host 
or domain name not found. Name service error for name=florina.renich.org 
type=: Host not found, try again)
Mar 21 14:52:26 basil postfix/qmgr[3804]: 3AF35240229: from=<m...@renich.org>, 
size=8480, nrcpt=2 (queue active)
Mar 21 14:52:26 basil postfix/smtp[12810]: 3AF35240229: 
to=<recipie...@host2.example2.com>, relay=none, delay=581, delays=581/0.01/0/0, 
dsn=4.4.3, status=deferred (Host or domain name not found. Name service error 
for name=florina.renich.org type=: Host not found, try again)
Mar 21 14:52:26 basil postfix/smtp[12810]: 3AF35240229: to=<m...@renich.org>, 
relay=none, delay=581, delays=581/0.01/0/0, dsn=4.4.3, status=deferred (Host or 
domain name not found. Name service error for name=florina.renich.org 
type=: Host not found, try again)
Mar 21 15:02:26 basil postfix/qmgr[3804]: 3AF35240229: from=<m...@renich.org>, 
size=8480, nrcpt=2 (queue active)
Mar 21 15:02:26 basil postfix/smtp[13022]: 3AF35240229: 
to=<recipie...@host2.example2.com>, relay=none, delay=1181, 
delays=1181/0.01/0/0, dsn=4.4.3, status=deferred (Host or domain name not 
found. Name service error for name=florina.renich.org type=: Host not 
found, try again)
Mar 21 15:02:26 basil postfix/smtp[13022]: 3AF35240229: to=<m...@renich.org>, 
relay=none, delay=1181, delays=1181/0.01/0/0, dsn=4.4.3, status=deferred (Host 
or domain name not found. Name service error for name=florina.renich.org 
type=: Host not found, try again)
Mar 21 15:22:26 basil postfix/qmgr[3804]: 3AF35240229: from=<m...@renich.org>, 
size=8480, nrcpt=2 (queue active)
Mar 21 15:22:27 basil postfix/smtp[13538]: 3AF35240229: 
to=<recipie...@host2.example2.com>, relay=none, delay=2381, 
delays=2381/0.01/0/0, dsn=4.4.3, status=deferred (Host or domain name not 
found. Name service error for name=florina.renich.org type=: Host not 
found, try again)
Mar 21 15:22:27 basil postfix/smtp[13538]: 3AF35240229: to=<m...@renich.org>, 
relay=none, delay=2381, delays=2381/0.01/0/0, dsn=4.4.3, status=deferred (Host 
or domain name not found. Name service error for name=florina.renich.org 
type=: Host not found, try again)
Mar 21 16:02:26 basil postfix/qmgr[3804]: 3AF35240229: from=<m...@renich.org>, 
size=8480, nrcpt=2 (queue active)
Mar 21 16:02:26 basil postfix/smtp[14418]: 3AF35240229: 
to=<recipie...@host2.example2.com>, relay=none, delay=4781, 
delays=4781/0.01/0/0, dsn=4.4.3, status=deferred (Host or domain name not 
found. Name service error for name=florina.renich.org type=: Host not 
found, try again)
Mar 21 16:02:26 basil postfix/smtp[14418]: 3AF35240229: to=<m...@renich.org>, 
relay=none, delay=4781, delays=4781/0.01/0/0, dsn=4.4.3,

Re: Name service error for name=* type=AAAA, when it should be IPv4

[Marvin Renich]

* Wietse Venema <wie...@porcupine.org> [170322 13:14]:
> Marvin Renich:
> > First, why would the DNS query correctly give the ipv4 address on Mar
> > 10, but then fail saying it could not find an ipv6 entry on Mar 21?  I
> > can find no configuration change or program version change that would
> > explain this.
> 
> Previously, the A lookup succeeded. Now, the the A lookup fails,
> then Postfix tries , and that fails, too. Postfix only logs the
> last DNS error.
> 
> So the real question is why did the A lookup fail. You can avoid
> the IPv6 lookup by configuring inet_protocols in main.cf.
> 
>   Wietse

Thanks, Wietse and Noel.  Once the IPv4 delivery fails for some reason,
and Postfix tries IPv6 (which must fail for this relayhost), the message
is deferred.  Do subsequent redelivery attempts only try IPv6?  This is
what it looked like was happening, even if the failure was caused by
something else.

The message sat in the deferred queue overnight, with more than a dozen
redelivery attempts, all with the same result, even though during that
time I was able to correctly resolve the relayhost's IP.  postqueue -f
failed, but changing inet_protocols to ipv4 and restarting Postfix
delivered the message immediately.

Also, what about my third question:  was the serverfault answer only
useful if an smtp-ipv4 service is manually added to master.cf?

Thanks...Marvin

Name service error for name=* type=AAAA, when it should be IPv4

[Marvin Renich]

I'm having a new problem with ipv6.  I'm running Debian (mostly testing
release) on my laptop, with Postfix running simply to allow mutt to send
when I don't have connectivity.  The relevant postconf entries (full
postconf -n below):

inet_protocols = all   (default; not specified in main.cf)
relayhost = [florina.renich.org]:587

On March 10, I have this log entry:

Mar 10 08:59:49 basil postfix/smtp[10878]: C0CFC2401AA: 
to=, 
relay=florina.renich.org[64.150.161.163]:587, delay=1.5, 
delays=0.13/0.04/1.2/0.11, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 
84B16680B0)

That was the last successful delivery through relayhost.  The next
outgoing message was on March 21:

Mar 21 14:42:45 basil postfix/smtp[12587]: 3AF35240229: 
to=, relay=none, delay=0.47, 
delays=0.25/0.22/0/0, dsn=4.4.3, status=deferred (Host or domain name not 
found. Name service error for name=florina.renich.org type=: Host not 
found, try again)

Postfix was last updated on February 5, from Debian postfix 3.1.4-3 to
3.1.4-4.  etckeeper shows that the last changes to Postfix configuration
came from that upgrade on that date (dynamicmaps.cf, makedefs.out, and
/etc/aliases.db).  mail.log shows Postfix was restarted on March 3, 11,
12, and 18.

The DNS information for the relayhost has not changed in a long time,
and it has never had an ipv6 entry (I control the tinydns server that is
authoritative for that domain).  From my laptop, various tools (host,
dig, nslookup, dnsip) have no trouble resolving the relayhost's address,
returning the correct ipv4 address.  I even did a raw dump of the result
from getaddrinfo("florina.renich.org", "587", ...) and got the expected
result.

First, why would the DNS query correctly give the ipv4 address on Mar
10, but then fail saying it could not find an ipv6 entry on Mar 21?  I
can find no configuration change or program version change that would
explain this.

Second, I would expect that with inet_protocols = all that if an ipv6
lookup fails, it would try an ipv4 lookup.  Is that not the case?  Do I
need to explicitly specify which hosts should use ipv4?

Third, I found a serverfault.com post[1] from 2014 where the answer said
to use a transport map with an entry like

example.com smtp-ipv4:[mail.domain.com]

but it did not say anything about creating a service smtp-ipv4 in
master.cf; was this answer just missing that info?  Does the default
Postfix config have that entry, but the Debian package doesn't?  That
same answer said that with inet_protocols=all Postfix should try ipv6
first, then fall back to ipv4.

Since on my laptop, I am always sending through the relayhost, is the
best solution to just set inet_protocols = ipv4?  Is there a better
solution?

This is what I have done for now, and it works, but I have other Postfix
servers, including the one on the relayhost (which has not yet shown any
problem), and as it delivers globally, I would like to understand why my
laptop's Postfix is having trouble.

Thanks...Marvin

[1] http://serverfault.com/questions/577134/postfix-host-or-domain-not-found

# postconf -n
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
append_dot_mydomain = no
biff = no
home_mailbox = Maildir/
html_directory = /usr/share/doc/postfix/html
inet_interfaces = loopback-only
mailbox_command = procmail -a "$EXTENSION"
mailbox_size_limit = 0
mydestination = basil.localdomain, localhost.localdomain, localhost
myhostname = basil.localdomain
mynetworks = 127.0.0.0/8 [:::127.0.0.0]/104 [::1]/128
myorigin = /etc/mailname
readme_directory = /usr/share/doc/postfix
recipient_delimiter = -
relayhost = [florina.renich.org]:587
smtp_generic_maps = hash:/etc/postfix/generic
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_password
smtp_sasl_security_options = noanonymous, noplaintext
smtp_sasl_tls_security_options = noanonymous
smtp_tls_security_level = may
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated 
defer_unauth_destination
smtpd_tls_cert_file = /etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file = /etc/ssl/private/ssl-cert-snakeoil.key
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtpd_use_tls = yes

Re: using virtual_uid_maps with maildrop transport

[Marvin Renich]

[For clarity, I have re-added the remainder of my email that was snipped.]

* Wietse Venema wie...@porcupine.org [150801 16:58]:
 Marvin Renich:
  Whether you have one real user for all virtual users or a setup with one
  real user for each of many virtual domains, you must still have at least
  one real user,
 
 Nope, that is incorrect.  The UNIX kernel does not care if a UID
 or GID has a symbolic user-land name, and therefore virtual(8) does
 not require that, either. Your mis-conception invalidates all your
 further arguments.

I apologize for not making myself more clear.  When I said real user
it was to differentiate it from virtual user (i.e. the recipient user
name in the virtual domain).  user was not intended to imply user
name, only an identity (uid w/ or w/o an entry in /etc/passwd) that the
virtual(8) driver uses for delivery.

The point I was trying to make was that allowing a numeric uid is good,
but allowing the admin to choose between using a numeric uid or a user
name from /etc/passwd (or other user database used by getpwent(3)) is
better and has a significant advantage for migration or disaster
recovery.

  possibly many.  If the only way to specify the real
  user(s) is by numeric ID, then the configuration must be edited when
  moving the postfix setup to another machine (and depending on how it is
  edited, there might be a significant chance for mistakes).  If names
  were allowed, this would not be necessary.  In either case, you must
  ensure that the new machine has the appropriate real users with their
  Maildir folders.
  
  I don't see a reason to not allow names, and allowing names makes things
  easier.

These questions are on the same general topic, but do not depend on
whether the above suggestion is accepted or rejected:

  Btw, I do not see anything in either the virtual(8) man page or the
  descriptions of virtual_mailbox_maps, virtual_uid_maps, or
  virtual_gid_maps in postconf(5) that describes what happens if
  virtual_mailbox_maps has an entry for a virtual user, but
  virtual_uid_maps does not.  What real uid is used to deliver the mail?
  
  Also, if virtual_uid_maps has an entry for a user, but virtual_gid_maps
  does not, how is the real gid determined?

...Marvin

Re: using virtual_uid_maps with maildrop transport

[Marvin Renich]

* Viktor Dukhovni postfix-us...@dukhovni.org [150723 09:17]:
 Not possible.  The virtual_uid_maps parameter is a feature of the
 virtual(8) not the pipe(8) transport.  And it stores a numeric uid,
 not a login name.

Why do virtual_uid_maps and virtual_gid_maps require a numeric uid/gid?
Allowing names is much more robust.  If you migrate your postfix setup
to a different existing machine, or if you have a catastrophic failure
and restore by starting with a fresh distribution installation and then
restoring the postfix configuration from backups, the uid/gid's for the
real users that manage the virtual users may be different, but
presumably the names will be the same.  Now you have to fetch the old
passwd and group files and translate the numbers in the virtual_uid_maps
and virtual_gid_maps files.

Is there some security or other reason that I am missing to not allow
names?  If not, would a feature request to allow this be welcome?

...Marvin

Re: using virtual_uid_maps with maildrop transport

[Marvin Renich]

* Wietse Venema wie...@porcupine.org [150801 15:52]:
 Marvin Renich:
  * Viktor Dukhovni postfix-us...@dukhovni.org [150723 09:17]:
   Not possible.  The virtual_uid_maps parameter is a feature of the
   virtual(8) not the pipe(8) transport.  And it stores a numeric uid,
   not a login name.
  
  Why do virtual_uid_maps and virtual_gid_maps require a numeric uid/gid?
 
 The primary reason virtual(8) exists is to support non-UNIX accounts.
 For example, all mailboxes can have the same UID and GID. The local(8)
 delivery agent is for UNIX accounts only.

Whether you have one real user for all virtual users or a setup with one
real user for each of many virtual domains, you must still have at least
one real user, possibly many.  If the only way to specify the real
user(s) is by numeric ID, then the configuration must be edited when
moving the postfix setup to another machine (and depending on how it is
edited, there might be a significant chance for mistakes).  If names
were allowed, this would not be necessary.  In either case, you must
ensure that the new machine has the appropriate real users with their
Maildir folders.

I don't see a reason to not allow names, and allowing names makes things
easier.

Btw, I do not see anything in either the virtual(8) man page or the
descriptions of virtual_mailbox_maps, virtual_uid_maps, or
virtual_gid_maps in postconf(5) that describes what happens if
virtual_mailbox_maps has an entry for a virtual user, but
virtual_uid_maps does not.  What real uid is used to deliver the mail?

Also, if virtual_uid_maps has an entry for a user, but virtual_gid_maps
does not, how is the real gid determined?

...Marvin

Re: using virtual_uid_maps with maildrop transport

[Marvin Renich]

* Viktor Dukhovni postfix-us...@dukhovni.org [150723 09:17]:
 Not possible.  The virtual_uid_maps parameter is a feature of the
 virtual(8) not the pipe(8) transport.  And it stores a numeric uid,
 not a login name.
 
 You'll need to implement any required lookups in a wrapper
 program around the underlying maildrop transport.

Thanks.

...Marvin

using virtual_uid_maps with maildrop transport

[Marvin Renich]

I would like to use something like

virtual_mailbox_domains = domain1.org domain2.org
virtual_uid_maps = hash:/etc/postfix/virtual_uids
virtual_transposrt = maildrop

with

maildrop  unix  -   n   n   -   -   pipe
  flags=DRhu user=vmail argv=/usr/bin/maildrop -d ${user_from_virtual_uid_maps}
  ${user} ${domain} ${extension} ${recipient} ${nexthop}

to have some users of the virtual domain be mapped to regular local
users who may set up their own .mailfilter, but other users will be
mapped to a vmail user whose .mailfilter will sort the mail
appropriately (with an appropriate dovecot configuration to serve the
virtual users).  There may be more than one vmail user (vmail-domain1,
vmail-domain2, etc.), each serving a collection of virtual users.

Can I use the result of the virtual_uid_maps lookup as the -d argument
to maildrop?  Is there a better way to do this?

Thanks...Marvin

sender_bcc_maps on submission service

[Marvin Renich]

I have enabled the submission service in master.cf:

submission inet n   -   -   -   -   smtpd
  -o syslog_name=postfix/submission
  -o smtpd_tls_security_level=encrypt
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_reject_unlisted_recipient=no
  -o smtpd_client_restrictions=$mua_client_restrictions
  -o smtpd_helo_restrictions=$mua_helo_restrictions
  -o smtpd_sender_restrictions=$mua_sender_restrictions
  -o smtpd_recipient_restrictions=
  -o smtpd_relay_restrictions=permit_sasl_authenticated,reject
  -o milter_macro_daemon_name=ORIGINATING
  -o sender_bcc_maps=$outgoing_bcc_maps
  -o smtpd_milters=

Most of the above is the default (commented out) Debian jessie config,
which I have uncommented.  In main.cf I have:

recipient_delimiter = -
mua_helo_restrictions =
mua_client_restrictions =
mua_sender_restrictions =
outgoing_bcc_maps = regex:/etc/postfix/outgoing_bcc_maps

/etc/postfix/outgoing_bcc_maps contains:

/^(.*)@(.*)$/ outgoing-${1}@${2}

But I am not getting any bcc's.  Mail for outgoing-foo is correctly
delivered to outgoing.  Is sender_bcc_maps handled by cleanup or
incoming in a way that the submission-specific setting is ignored?  The
value of sender_bcc_maps for other than the submission service is empty.

Thanks...Marvin

Re: sender_bcc_maps on submission service

[Marvin Renich]

* Wietse Venema wie...@porcupine.org [140722 12:59]:
 sender_bcc_maps is not implemented by smtpd(8) but by cleanup(8).
 This is consistent with the information in the manpage.

Okay, now I see it in cleanup(8); I was looking in postconf(5) under
sender_bcc_maps.

 You can work around this with:
 
 /etc/postfix/main.cf:
 submission ...
   -o cleanup_service=cleanup-outbound
 
 /etc/postfix/master.cf:
 cleanup-outbound .. .. .. .. cleanup
   -o sender_bcc_maps=$outgoing_bcc_maps
 
 So it is possible, but it is not obvious.
 
   Wietse

Thanks!  That is just what I wanted.  I assume your /etc/postfix/main.cf
above was a typo, and both snippets should be in master.cf?  I'll let
you know if it works.

...Marvin

Re: sender_bcc_maps on submission service

[Marvin Renich]

* Marvin Renich m...@renich.org [140722 13:12]:
 * Wietse Venema wie...@porcupine.org [140722 12:59]:
  /etc/postfix/main.cf:
  submission ...
  -o cleanup_service=cleanup-outbound
  
  /etc/postfix/master.cf:
  cleanup-outbound .. .. .. .. cleanup
  -o sender_bcc_maps=$outgoing_bcc_maps
 
 Thanks!  That is just what I wanted.  I assume your /etc/postfix/main.cf
 above was a typo, and both snippets should be in master.cf?  I'll let
 you know if it works.

After s/cleanup_service/cleanup_service_name/ it worked perfectly.

Thanks much!

...Marvin