[pfx] Re: SMTP Smuggling, workarounds and fix

[Matthias Andree via Postfix-users]

Am 30.12.23 um 18:42 schrieb Mike via Postfix-users:

On 12/30/2023 12:08 PM, Wietse Venema via Postfix-users wrote:

"Hakon Alstadheim wrote:

Just FYI, I got postfix 3.7.9-0+deb12u1 from bookworm-updates (i.e.
Debian) today.

Scott Kitterman:

For those still using Debian Bullseye (oldstable), postfix
3.5.23-0+deb11u1 is also available from bullseye-updates.  Both
of these stable updates were released yesterday.

fwiw, this update to the postfix port on FreeBSD (I'm running 13.2) came
through yesterday:

postfix-3.8.4,1


Re FreeBSD, while we are rarely in a hurry to update Postfix:
The up-to-date ports and 2023Q4 quarterly ports trees (which can both be
checked out via Git) has carried the update since Dec 23 Europe
afternoon thanks to Juraj Lutter's work. The delay is due to package
build servers' schedules.


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

[pfx] Re: 25 years today

[Matthias Andree via Postfix-users]

Am 14.12.23 um 14:20 schrieb Wietse Venema via Postfix-users:

As a few on this list may recall, it is 25 years ago today that the
"IBM secure mailer" had its public beta release. This was accompanied
by a nice article in the New York Times business section.

There is some literature at https://www.postfix.org/press.html that
attests how this project accelerated open-source adoption by a very
large company.

At the time there were several efforts by people inside IBM to do
open-source projects, but it was the NY Times article that brought
open source on the radar of the CEO. He then tasked people to come
up with an open-source strategy for IBM.

As for the name Postfix, my colleagues and I had come up with
multiple names that were rejected each time (I still have some
Internet domains names from that time). We decided that this was
not going to work, released it as "IBM secure mailer", and then,
after IBM was no longer in control, changed the name to Postfix.

That was a long time ago. Postfix has evolved as the Internet has
changed. I am continuing the overhaul of this software, motivated
by people like you on this mailing list.



Dear Wietse,


gefeliciteerd met je secure mailer aka. Postfix!


I was one of the early adopters of the and after evaluation, and at the
time, quickly found it suited my/our needs best, so it has since been my
mail software for small office, home server, and even home computer setups.

It is a software I have always found of exemplary compatibility with its
older version, smoothest upgrade path, and it had early-on already, and
over time even more so, always stayed modern, approachable and suited so
many different settings for me.

Thank you very much for maintaining it over this eternity of time and
still always keeping it up to date.

Dank je wel!

All the best,
Matthias


___
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.

[Matthias Andree via Postfix-users]

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.

___
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.

[Matthias Andree via Postfix-users]

Am 10.03.23 um 11:07 schrieb Jaroslaw Rafa via Postfix-users:

Dnia 10.03.2023 o godz. 18:18:50 Phil Biggs via Postfix-users pisze:

Likewise, To keep my mail client's threaded view sane I resorted to using
header_checks:

/^Subject: \[pfx\] (.*)$/ REPLACE Subject: $1

What a mail client has problem with threading because of a tag in the
subject?

Threading is supposed to work based on "Reference:" and/or "In-Reply-To:"
headers. Only in lack of those, it falls back to subject (my mail client
also specially marks such messages in the thread to signal this fact).

I have no problems with threading regardless any tag being present in the
subject, its position, or lack thereof.


For excruciating correctness, no. The relevant header is called
"References:" (-> RFC 5322), and it's not "and/or", but "and", and
clients are supposed to create both. I wish mailing list drivers
enforced this and rejected anything that has something like Re: AW:
Re^99: or thereabouts in the subjects and not both References: and
In-Reply-To: headers, to get people to use proper tools for
participation in lists.

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

Re: "Best" way to stop postfix from sending any DSN

[Matthias Andree]

Am 31.12.22 um 05:29 schrieb Sean Hennessey:


I'm doing some testing and am trying to figure out a way to set up
postfix so that it won't ever send a DSN.



What is the use case for that other than bulk sending of unsolicited
e-mail?
Normally operators will want to know what addresses to remove from the
distribution lists, even for newsletters.

Re: Spammer succeeded in relaying through my server

[Matthias Andree]

Am 24.12.22 um 03:28 schrieb Samer Afach:

Dear Raf:

That's actually what I do on all the bare-metal machines, but from my
understanding of how docker works, every container is made to run
exactly one service, and somehow default Linux images disable system
services. They can be re-enabled, but it's not the way it's meant to
work, and given that I'm just a beginner in this whole docker thing,
I'm trying not to jump over rooftops before some time passes by and I
feel comfortable with everything I've done so far and build the
confidence of "It worked for a while, now let's try changing that one
thing".

This can get much worse for beginners, and it took me a while to get
email working properly. If you notice in my setup, you'll see that
postfix, dovecot and OpenDKIM each is running in its own container
(and they all must be running in foreground mode to access logging).
Luckily, sharing socket files in Linux is allowed among containers,
and the reasoning there, if I understand correctly, is that all these
containers use the same kernel, and that's the only required
condition. This simplified my setup a lot. Over time I'll have to move
everything to inet and stop using socket files because it sounds dirty.


Whether you expose one IP socket or one filesystem unix socket - what's
the difference? Either punches a dedicated hole into the container's
isolation layer.



The worst part in all this is OpenDKIM. It doesn't support stdout
logging, which means I have to force the rsyslog service to work to
see any errors, but given that its docker should start with exactly 1
program in the foreground, I don't know how to print the logs with
something like tail since OpenDKIM is running in the foreground.
Another problem to be looking into soon when I'm done with all these
more prior piling issues.


For manual debugging, docker exec and running a shell or tail is what
you will be looking for, with similar options to those you give to
docker run - only that exec assumes a running container and puts a
second process into it, rather than creating one from an image.

And then I wonder if it's about time to suggest unprivileged mode, or
podman for that matter...

Regards,
Matthias

Re: Spammer succeeded in relaying through my server

[Matthias Andree]

Am 23.12.22 um 13:35 schrieb Samer Afach:

Dear Matthias:

I completely agree with you. My only contention is that some times
simple solutions with simple assumptions are good enough, instead of
developing a nuclear silo for something that can be tested in an hour
and then tested with public tools. Reminds me of the "email regex" vs
"send that email already" debate, plus all the jokes on "automate it"
or "just do it". No need to get into details there. Let's move on from
this point, because I have a feeling we'll never agree here. Apologies
if I'm sounding too naive.

Anyway, it seems that using HAProxy's proxy protocol circumvented all
the networking issues, and now Postfix and Dovecot can recognize all
clients properly. It seems that so far everything is going according
to the plan. :-)



See what I mean...  you thought you had it covered, only to find out
later there was yet more to do (letting haproxy convey client IP
information).



About your great loud thought, my containers are versioned but there's
no CI in there, and every launch for them recreates them. They're all
based on either Debian or Ubuntu (depending on support for my
applications), which means they'll be updated automatically. I don't
use random images from untrusted sources. There's even plan to run apt
update/upgrade on every launch to ensure everything is up to date even
if I forget to recreate a container for any reason, and I'm planning
cron jobs that'll restart the containers daily. I really appreciate
your loud thoughts, keep 'em coming, and I hope I have it covered that
one with my plan.

I wouldn't call this a complex setup. In fact, I don't even know what
a simple setup would be... bare-metal? This is the problem I'm solving
for actually. Done that for a decade already. Bare-metal is stateful
and whenever I have an issue with the physical server I have to start
over, work for a week, and potentially misconfigure things because of
details I forget, again and again and again? I disagree, this setup is
only "complex" the first time, and I'll understand its intricate
details over time (like everything else in system administration).
Once it works, all I need to do is to pipe the proxy lines to the
containers' open ports and I'm done... possibly for life;
realistically for 5-20 years (depending on how big Debian changes over
the years will be). Even if my server needs to be moved, no problem. I
just tar the images and data, send them over to another physical
server, change the proxy destination, and done. A plus is, no worries
about malware, because things get rebuilt, and whenever I have a
suspicion, I just wipe everything physical and restart with minimal
effort. The merit of this setup is priceless. This abstraction is a
whole another level. I'll do my best to learn everything I can in this
vacation to cover all my basis.



Yes, that "rebuild" has some value, if you rebuild from trusted sources
- but whether you rebuild a container image or a bare-metal
configuration does not make much difference to me. Either will bring at
least postfix's master.cf, main.cf and some tables on usual setups.

Whether your container base image updates or you update your distro
yourself, either way you need to work through release notes and
revisit/update your configuration. Of course a proper proxy/container
setup may ease scaling and migrating across hosts.


At least while you are using convenience distribution setup templates as
you will often find with Debian and its freeriders^Wderivatives. And
complex as in "you need to tell the proxy and the proxied service to
interact". A bare metal postscreen does not need that.



And please, let's not pretend that VMs are simpler than containers (in
case that's the answer to that question about simplicity)... oh, my...
vSphere and/or KVM are a whole other monster that need resources and
management and introduce their own problems.



I have not implied that they were, but they are ONE means to implement
an inside/outside testing setup without actually exposing things to the
unfriendly world.




Cheers,
Sam


On 23/12/2022 1:51 PM, Matthias Andree wrote:

Am 23.12.22 um 03:19 schrieb Samer Afach:

Dear Matthias,

I think there's a misunderstanding here. The server is already
shutdown. I thought you meant that I should shutdown the server
permanently and move on with my life because I'm incapable of running
a server, which seems to have been the context (I'll explain next why
that's obvious). But please allow me to elaborate that usually the
cost of that is extremely high, and I'm willing to pay it. Luckily I'm
on vacation now so I'm just spending my own time to do this. I've
spent so far no less than 100 hours on this fiasco. Zero regrets.

Btw, the relays happened because I activ

Re: Spammer succeeded in relaying through my server

[Matthias Andree]

Am 23.12.22 um 03:19 schrieb Samer Afach:

Dear Matthias,

I think there's a misunderstanding here. The server is already
shutdown. I thought you meant that I should shutdown the server
permanently and move on with my life because I'm incapable of running
a server, which seems to have been the context (I'll explain next why
that's obvious). But please allow me to elaborate that usually the
cost of that is extremely high, and I'm willing to pay it. Luckily I'm
on vacation now so I'm just spending my own time to do this. I've
spent so far no less than 100 hours on this fiasco. Zero regrets.

Btw, the relays happened because I actively changed mynetworks_style
to subnet, forgetting and not checking that all incoming connections
will come from the gateway of docker subnet. Still under research to
identify how that works.

There have been suggestions on the email list that I could start the
containers locally to do the experiments. Maybe I'm missing something,
but isn't the primary problem that I need to identify connection
sources with the PROXY protocol? How will I do that if I can't produce
remote connections? There's no way to guarantee that unless I do that
remotely. That's why I'll have to turn on the server before it's fully
tested... because the ultimate test will be communicating with the
server remotely and getting the desired results.

And again, let's not forget that disabling email relaying is the
primary solutions (as many have pointed out already). So none of this
is that bad. I think we have a fair assessment of the risk, all things
considered.

Now about learning, people have shared interesting opinions and I read
the email chain (readers, please read them first before commenting on
what I'm saying) and I agree with many of them and disagree with
others, and yes, it's not as simple as it seems. There's no point in
anyone's life where one said "now I'm educated, let's run an email
server". Not really. Even people graduating university don't know what
they're doing after having spent years grinding information. The
reason for this phenomenon is complex and has to do with human nature
and upbringing, but it's what it's. You either inherit a system that
works and you're taught the caveats in it and how to test it and what
to look for, or you start from somewhere (some configuration online?)
and learn as you go. The Linux ecosystem in general is based on
testing things manually, which is why configuration mistakes happen
all the time, and which is why there are tons of online tools to test
the obvious vulnerabilities (OSS, etc, most of which use public
interfaces, because no one knows everything). Email is very sensitive,
granted, but I'm sorry, you're asking for the impossible. You're
asking for people to "learn first", well, I have news for you... THIS
is what learning looks like :-)

There's a saying I like: Experience is the number of mistakes you've
done so far.

You're asking for "safe and possibly reviewed configuration", I'm
sorry, but that doesn't really mean anything in practice unless you
have an army of experts to support you. It's just words that sound
nice. Even with all the wonderful people here and all the help I got,
when I shared my configuration, I barely got commentary on my
configuration, and when I asked further I got your email asking me to
"learn". It didn't take more than one email admitting my ignorance to
start getting requests to shutdown my server (which I had already
done), instead of providing more information. That's not odd, it's
just human nature, which leads to where we are right now. Please don't
misunderstand what I'm saying, I'm in NO WAY entitled to anything, and
I'm already very grateful for everything I learned here, but please be
realistic in what you're asking for. I'm trying to make the best of
the current situation.

Thank you all, lovely people. I wanna emphasize that I'm learning from
every email I'm reading here.

Best regards,
Sam


Sam,

So it appears that there is some understanding, but what I am saying is
- what other people have also written in different words - is that you
are using a rather complex setup.

Containerization with its isolation may serve some purposes, but
requires extra attention - and unless I missed something in the entire
thread, you have not written any pondering of your docker networks
either, starting from  and selecting
the right one.
I am wondering if I should ask whether you have a CI pipeline set up
that allows you to exchange the base image with a flick of your finger
and reliably rebuild your containers, if some system component (think
libc or your TLS stack) needs updates.
Ooops. That was a pretty loud thought that slipped through my fingers
and keyboard into the world.

Regarding setting up testing, it's easy enough to create another local
network (formerly called alias addressers) on your container host, and
route it to your container host explicitly, and from there route it back

Re: Spammer succeeded in relaying through my server

[Matthias Andree]

Am 22.12.22 um 01:47 schrieb Samer Afach:

Thank you, Matthias, for your opinion.

Ironically, the proxy part in this whole story is not only the simple
part that I fully understand, but also the part that's very easily
testable with my current knowledge and understanding of networking.
It's easy to look into the IP addresses of incoming connections and
cross-check them with the senders. It's easy to see whether a PROXY
protocol with HAProxy works. I'm looking into that setup as we speak.
All that is easy. I'm actually surprised you're using that part as
argument to why I should shutdown my server.

Thanks to the wonderful people in this email list, now I understand my
mistake with that regard. I learned a lot.

If I were you, I'd focus on my lack of understanding of the email
protocol. Now that, is a part that I still cannot fully understand,
embarrassingly so. I still don't know what ehlo means, except that
it's the first message. I don't know why it matters what address we
put after it. That does make me look like an idiot, doesn't it? :-)

I fully understand your opinion and why you'd want me to shutdown my
server. But if I were you, I'd try to encourage people to learn more
or explain more to them. This whole incident reminds me of people who
fall for scams and pay scammers money. They can be ashamed of it and
never talk about it, or try to learn how to not fall for it again.
Just my humble opinion.


Sam,

your proxy is what underminded Postfix's relay guards, by your own
assessments and descriptions - because it was the proxy that connected
with its own IP address to Postfix's smtpd, and $mynetworks subnets are
usually permitted to relay.
So while you may have understood how the proxy itself works, you have
not identified the implications for operating a mail server proofed
against unintended relaying.
Reading Postfix's documentation thoroughly would have brought you across
XCLIENT (and I was saying application-level or -layer proxy because it
talks SMTP not TCP), and you would have asked specific questions.

And why does your server have to go online BEFORE you have learned the
ropes? I did not ask you to shut down permanently (that should have been
clear, but you are getting defensive so I may have stepped on your toes
after you stepped on the public's), but implied to first learn and then
go online with a safe and possibly reviewed configuration. The public
constantly has to put up with people who experiment in public and ask
for help *after* accidents. Not sure where such dangerous approaches are
taught.

Postfix has been around for a quarter century, and it has always been
*the* example of good design, documentation and compatibility with
predecessor versions.

I would really appreciate if people in general learned BEFORE putting
systems live.

Cheers,
Matthias



Cheers,
Sam



On 21/12/2022 10:21 PM, Matthias Andree wrote:

Am 21.12.22 um 09:45 schrieb Samer Afach:

Thank you for these hints, Benny. I wanna point out that I'm, in no
way, an expert in any of this, and my configuration is based on online
research and some copy/paste.



Then with all due respect, please shut down your mail server and do not
start it again until you have fully understood what your services are
doing, and need to do instead in order to be operated securely. We don't
need more public accidents.

Postfix has ways to let application-level proxies convey actual client
IP (XCLIENT). You will want those in the logs, and not your proxy's IP
address. Sooner or later you will find it necessary to at least
temporarily block offending subnets.

If your proxy can't do that, or you don't know how, or you don't know
how to do that with containers, perhaps use postscreen instead and run
your Postfix on a bridged networked container of VM instead.

I do not believe you (personally - no offense, but after your statement
above) are currently fit for setting up and operating such a complex
setup as you are using with several proxy and NAT layers and all that.
Containers may seem like a good idea, but if they dispose of crucial
information such as the client address, then revise your setup
THOROUGHLY.

Sorry to be blunt without asking, but we've all had our shares of eating
unsolicited e-mail.

Thank you.


S

Re: Spammer succeeded in relaying through my server

[Matthias Andree]

Am 21.12.22 um 09:45 schrieb Samer Afach:

Thank you for these hints, Benny. I wanna point out that I'm, in no
way, an expert in any of this, and my configuration is based on online
research and some copy/paste.



Then with all due respect, please shut down your mail server and do not
start it again until you have fully understood what your services are
doing, and need to do instead in order to be operated securely. We don't
need more public accidents.

Postfix has ways to let application-level proxies convey actual client
IP (XCLIENT). You will want those in the logs, and not your proxy's IP
address. Sooner or later you will find it necessary to at least
temporarily block offending subnets.

If your proxy can't do that, or you don't know how, or you don't know
how to do that with containers, perhaps use postscreen instead and run
your Postfix on a bridged networked container of VM instead.

I do not believe you (personally - no offense, but after your statement
above) are currently fit for setting up and operating such a complex
setup as you are using with several proxy and NAT layers and all that.
Containers may seem like a good idea, but if they dispose of crucial
information such as the client address, then revise your setup THOROUGHLY.

Sorry to be blunt without asking, but we've all had our shares of eating
unsolicited e-mail.

Thank you.

Re: PCRE2 error

[Matthias Andree]

Am 17.02.22 um 10:10 schrieb Carlos Velasco:

Hi,

Trying to test latest postfix 3.7.0 with PCRE2 I have found a problem
in building documentation.

According to PCRE_README (http://www.postfix.org/PCRE_README.html),
pcre2-config is used:
"AUXLIBS_PCRE=`pcre2-config --libs`"

But "pcre2-config" doesn't have "--libs" as available argument.

# pcre2-config --help
Usage: pcre2-config [--prefix] [--exec-prefix] [--version] [--libs8]
[--libs-posix] [--libs32] [--libs16]  [--cflags] [--cflags-posix]

Confirmed in debian manpage and source code
https://manpages.debian.org/stretch/libpcre2-dev/pcre2-config.1.en.html
https://github.com/PhilipHazel/pcre2/blob/master/pcre2-config.in


The quick approach would be #define PCRE2_CODE_UNIT_WIDTH 8 in an
appropriate place in the headers (or adding -DPCRE2_CODE_UNIT_WIDTH=8 to
the compiler arguments) and using pcre2-config --libs8 to get the proper
libs argument (-lcpre2-8 on my computer).

Re: Some README files are not included in the postfix-files

[Matthias Andree]

Am 21.01.22 um 00:06 schrieb Wietse Venema:

Jaroslav Skarvada:

Hi,

it seems the following README files are not included in the conf/postfix-files:
BDAT_README
MAILLOG_README
POSTSCREEN_3_5_README
SMTPUTF8_README

Is it intended?

Yikes, these are all "new" files added with Postfix 3.x.

I'll add a pre-release check for that.


Wietse,

so after years and years I have been able to find a glitch, which is an
extremely rare occasion, that is to say:

Thank you for the continued attention to Postfix's high quality, in-depth.
Appreciated for decades, literally. Dank U zeer.

Regards,
Matthias

Re: No current announcement for Postfix 3.6.4

[Matthias Andree]

Am 16.01.22 um 06:43 schrieb * Neustradamus *:

Thanks for your reply!

I think that the best solution is to do all announcements when you publish, no 
several days after!
Mirrors are slow and a lot of are dead, I have requested cleaning: 
https://marc.info/?l=postfix-users&m=164223870828454&w=2

Look the problem here, for example: 
https://www.reddit.com/r/postfix/comments/s49iy8/postfix_364_released/

The more important place is the official place.

Thanks in advance.


Neustradamus,

Can you please stop pestering the open source world with insistence on
and request for patterns and features and behaviors you would surely not
even see from paid commercial providers?

Maintainers will announce new releases when they see fit, not when some
pseudonymous poster requires so,
and protecting the "quicker" mirrors from being hammered down by
requests is a legit reason to delay announcements.
Unless you want to provoke losing quick mirrors, that is.

Now please keep calm and move on, there is nothing to see here.

Thanks in advance.

Regards,
Matthias Andree
(who has been using Postfix since long before it was called 1.0, 23-ish
years now, just sayin' I have been around for a while)

Re: TLS and Android clients

[Matthias Andree]

Am 15.12.21 um 23:35 schrieb Benny Pedersen:

On 2021-12-15 23:04, raf wrote:


How could I get an Android client and a Postfix server work together
please?



It's just a guess, but maybe the problem is ECDSA.
If you add an RSA key as well, it might work.
Does that sound plausible?


or simply try smtps if submission fails on android

i use aquamail on android with succes smtps / imaps (ssl not tls)


Benny,

Please do not confuse protocol versions with how TLS
handshake/negotiation is introduced.

SSL is the obsolete and unsafe predecessor to TLS but that or the TLS
version has NOTHING to do with
whether you either: use dedicated SSL-wrapped = TLS-wrapped = Implicit
TLS ports for TCP,
or: start a vulnerable clear-text connection that starts at application
level, then proceeds through STARTTLS or STLS to negotiate TLS,
and when many applications forget to reset their state[1 below]

Standing recommendations are to use TLS v1.2 or newer. Obsolete clients
may want to talk TLS v1.1 or v1.0 though but should be upgraded or
phased out.

If you want to make a distinction between negotiation, i. e., whether
the TCP session starts with TLS handshake right away (called "Implicit
TLS" or "TLS-wrapped on dedicated "...s" ports smtps/imaps/pop3s on
465/993/995) or cleartext initial conversation that negotiates TLS
in-band (STARTTLS for SMTP and IMAP, STLS for POP3 on ports 25/587, 143,
110, respectively), then make that clear. Anything else is coincidental
and adds to the confusion.

Thank you.

[1] After the Poddebniak et al. paper&presentation earlier this year,
Implicit TLS would get my preference, it is also cleaner and does not
mix application and security layers in ways that require special attention.
https://www.usenix.org/conference/usenixsecurity21/presentation/poddebniak

Re: Postfix Maildir problems, with maildrop

[Matthias Andree]

Am 29.12.19 um 00:01 schrieb Richard Rasker:
> Hello Wietse,
>
> Op 28-12-19 om 23:54 schreef Wietse Venema:
>> Richard Rasker:
>>> Yes, I have specified the use of Maildir in main.cf:
>>>
>>>  home_mailbox = Maildir/
>> That Postfix setting has no effect on /usr/bin/maildrop, because
>> /usr/bin/maildrop is NOT part of Postfix.
>
> I figured that much already. However, I still haven't found a way to
> disable it, and the man page doesn't say anything about configuring
> the destination. So I decided to ask around here to see if more people
> are using it with Postfix.

I have been using maildrop successfully for Maildir delivery. I
recommend to also look at the man pages for maildropfilter (in older
installations, see man maildroprc instead), and perhaps maildropex.

Look for the description for the DEFAULT variable, and look whether your
Postfix rig is running in delivery mode (-d ... on maildrop's command
line).

(Personally, when my mail servers were running some medium-sized traffic
loads, and things were still running from hard disk drives (pre-SSD), I
switched from Courier-IMAP to Dovecot and use its local delivery agent
on some of my setups, but Dovecot comes with its own complex
configuration, so I suggest to not do that before you've fixed your
delivery to Maildir.)

>
> But maybe I should simply try and remove courier-maildrop, and see
> what happens.

Before you go skeet shooting blindfolded, better figure out what the
delivery mechanisms really are. In doubt, postconf -n shows the
nondefault main.cf parameters, and postconf -M shows the master.cf
parameters.
maildrop might be called from a transport as well if you're using a
mailbox transport. Without a complete list of nondefault configuration
options, however, it's all just a big ugly riddle that no-one is keen on
solving. So if you can't figure it out for yourself, please post those,
and /etc/maildroprc and a user's .mailfilter, if any.

Re: SCRAM

[Matthias Andree]

Am 08.09.19 um 07:29 schrieb - Neustradamus -:
> For a better security, look the RFC6331: Moving DIGEST-MD5 to
> Historic: https://tools.ietf.org/html/rfc6331
> .
>
> It is about DIGEST-MD5 (and CRAM-MD5 in the same time).
>
> You must to inform that SCRAM-SHA-XXX(-PLUS) is here!
>
> Regards,
>
> Neustradamus


Dear Neustradamus,


you've made your point, now please leave the lobby.


Postfix isn't supposed to pamper up the world for what certain
combinations of circumstance could do wrong.


Your pulling out detail decisions leaves the entire system setup out of
the picture, and quite a few of those digest algorithms will require to
store UNSALTED UNENCRYPTED passwords server-side vs. cleartext over
trusted TLS channels can get away with salted PW hashes that are far
harder to break in case of a server-side security breach.


You have repeatedly been explained that Postfix pulls in SASL providers
by reference, so their lobby is where you should linger.


Now please get back to Postfix-related topics that don't assume you can
run MTAs without mapping the field first, or stop mailing to the list.


Regards
Matthias

Re: Fetchmail final delivery problem

[Matthias Andree]

Am 27.12.18 um 02:05 schrieb Andrey Repin:
> Greetings, Wietse Venema!
> 
>> Andrey Repin:
>>> Greetings, All!
>>>
 I think I just broke my mail system. I'd like a quick help if possible.
 I have a remote server that accepts the mail for domain right now.
 The mail is retrieved from it by fetchmail and pushed to the local postfix
 instance to be delivered to the user mailboxes using
>>>
 mda "/usr/sbin/sendmail -iG -N never -f %F -- %T"
>>>
 The problem is, only virtual recipients are delivered correctly.
 An attempt to deliver mail for real users end in message being trashed with
 "delivery loop detected".
 The log says "bounced", but it is nowhere to be found. Not on postmaster,
 neither on the sender's address.
>>>
>>> Ok, I've managed to capture a bounce.
>>> Here's headers of a message that was received (and bounced) by postfix.
>>> Yes, the final destination is alexa...@ccenter.msk.ru, and the user actually
>>> exists.
> 
>> Rule number one: email routing MUST NOT depend on the message
>> header content and it MUST NOT depend on the message body content.
> 
> It's neither. I have explicitly set final destination for each remote account.
> If there any way to work around it, until the migration is done and the remote
> server is decomissioned?

Without fetchmail configuration details and logs, it's too hard to debug
remotely.

As Wietse stated, %T might be dangerous, if it's a single-user mailbox,
you might as well just specify the user's name instead.  Else you _must_
make sure that fetchmail can properly derive envelope recipient headers
(assuming that your mailbox stores them in some form), and that in turn
assumes that your fetchmail configuration makes for a constant
recipient...

In which case you need to make sure that the messages you inject from
fetchmail does not end up in the mailbox you are fetching from - which
is what might be happening.

For the fetchmail end, see
 (again, remove passwords).

Re: Berkeley DB reads DB_CONFIG from cwd

[Matthias Andree]

Am 11.06.2017 um 20:50 schrieb Wietse Venema:
> Philip Paeps:
>> On 2017-06-11 14:07:36 (-0400), Wietse Venema  wrote:
>>> Oh, and it will of course open a DB_CONFIG file in whatever happens to 
>>> be the super-user's cwd when they invoke the postmap or postalias 
>>> command, so this is not just a matter of set-gid Postfix commands.
>>>
>>> [...]
>>> -if ((errno = db->set_cachesize(db, 0, dict_db_cache_size, 0)) != 0)
>>> -   msg_fatal("set DB cache size %d: %m", dict_db_cache_size);
>> Is this change intentional, or did it sneak in?  It seems unrelated to 
>> the environment workaround.
> dbenv->set_cachesize(dbenv, 0, dict_db_cache_size, 0) rejected a
> call with the Postfix default cache size, and there appears to be
> no API to find what cache size it would have accepted. Screw it.
> This library needs to die.

Hi Wietse,

sorry for the techy noise on a users list in this post. There may be
valid reasons for killing off Berkeley DB, but your using it counter to
the specs is not one :-)

Explanation: BDB did not reject the size, but it did reject your attempt
to call db->set_cachesize(...) when the "db" handle was created and
initialized with a non-NULL dbenv (the db_create(&db, dbenv, 0) call below).

Meaning that:
You are attempting to set the cache size on the /database/ (not the
/environment/). The documentation of Berkeley DB states it is an error
to set the cache size for databases opened within an environment (i. e.
with a non-null dbenv used in db_create()), because the database uses
the cache from its environment. Before your patch, there was no
environment (the dbenv argument was 0 in your db_create() call), so it
was permissible to call db->set_cachesize().

So instead of calling db->set_cachesize, you now - after introducing the
environment - need to call dbenv->set_cachesize, (the _env_ being the
important addition), so that you set the cache size on the environment
(dbenv variable in your code) instead.
We've been doing that successfully in bogofilter for more than a decade
across various Berkeley DB versions.

You can no longer use this:
*
https://docs.oracle.com/cd/E17275_01/html/api_reference/C/dbset_cachesize.html
"Because databases opened within Berkeley DB environments use the cache
specified to the environment, it is an error to attempt to set a cache
in a database created within an environment."

You need to use this:
*
https://docs.oracle.com/cd/E17275_01/html/api_reference/C/envset_cachesize.html

and you best set it very early, *before* the dbenv->open.


Note that the fatal error messages in the code are also misleading here
in two places - all these marked calls create are the in-memory
structures ("handles"), the actual environment or database, are only
created on their respective ->open() calls.
> +/* Fix 20170611 workaround for undocumented ./DB_CONFIG read. */
> +if ((errno = db_env_create(&dbenv, 0)) != 0)
> + msg_fatal("create DB environment: %m");
here ^^ I suggest:

msg_fatal("create DB environment handle: %m");

> +dirname_buf = vstring_alloc(100);
> +if ((errno = dbenv->open(dbenv, sane_dirname(dirname_buf, db_path),
> +DB_INIT_MPOOL | DB_CREATE | DB_PRIVATE, 0)) != 0)
> + msg_fatal("open DB environment: %m");
> +vstring_free(dirname_buf);
> +if ((errno = db_create(&db, dbenv, 0)) != 0)
>   msg_fatal("create DB database: %m");

here ^^ I suggest:

msg_fatal("create DB database handle: %m");

HTH
Matthias

Re: Postfix 20 years ago

[Matthias Andree]

Am 12.02.2017 um 19:06 schrieb Wietse Venema:
> Last month it was 20 years ago that I started writing Postfix code.
> After coming to IBM research in November 1996, I spent most of
> December and January making notes on paper. I knew that writing a
> mail system was more work than any of my prior projects.
>
> The oldest tarball, dated 19970220, contains library functions plus
> two early versions of the master daemon. There are 8086 lines of
> code, 4204 lines after stripping the comments, and the only
> documentation was my pile of hand-written notes.

Dear Wietse 'Dr. Postfix' Venema,

I am pleased to see that you are still in charge of the MTA that has
already come of age.

When I began switching my - mostly qmail - setups to Postfix in the late
1990's, setting it loose into production long before 1.0 was on the
horizon, with good success, it required far less of my attention than
any other MTA afoot at the time.

While sendmail was going through rough times, being overrun by the bad
guys on Internet, to recover quite a bit later, and qmail was slowing
down magnetic spinning disks with ridiculous amounts of synchronous
writes and bouncing spam with counterfeit senders it had previously
accepted responsibility for, and many other MTAs and MDAs of that time
have fallen into disrepair, neglect, oblivion, or some other abyss,
Postfix has prevailed, along with a few other grown-up MTAs that I care
less about.

At the time, around 1999, I haven't thought much about the longevity of
Postfix, which was the best mailer for my needs at the time, and whether
it would be for two or five years was long enough, be that home or
production use, and I had always feared you'd move on to other
projects.  I see - with delight - that you are still around and busy
with Postfix, and I feel that your hand has guided Postfix well through
many many years, and if there is one project where a sound design of
compatibility shows and shines brightly, and makes it a really
pleasurable experience as user or admin to not be surprised in nasty
ways, then it is Postfix.

Thank you - and IBM, and the other major contributors - so much for the
continued contribution of an important piece of backbone software that
"just works". It's been a ride I've always enjoyed and continue to
enjoy, and I hope that when the day comes that you move on to other
projects, that there will be a maintainer with a similar sense of
continuity. I would never have bet on even a decade, and even though I
haven't put anything at stake other than my time, well done, keep going.

Thanks again!

Cheers,
Matthias

Re: Make smtp client talk through SSH tunnel?

[Matthias Andree]

Am 04.01.2017 um 12:47 schrieb Wietse Venema:
>
> You need to make smtp(8) talk to a TCP port (or UNIX-domain port),
> an arrange for a little daemon that listens on that port, and that
> invokes ssh when a connection is established to that port. Then
> the little daemon shuttles bits up and down. Such an on-demand
> TCP relay could be done in Perl, Python, or any capable language.

Thanks. The TCP relay and asynchronous or triggered start (even through
autossh) is exactly what I'm considering brittle and am trying to avoid;
I am looking for something synchronous. Looks like we still don't have
that without someone extending the smtp client's source code.

Make smtp client talk through SSH tunnel?

[Matthias Andree]

Greetings and a happy new year,


I still am in a situation where I occasionally need to have an SMTP
client (preferable Postfix's) talk through an SSH tunnel.

I know we have the smtp(8) client, and we have the pipe(8) client for
injecting RFC5322 stuff into commands, but what I need is some form of
the smtp(8) client talk to the ssh command (with certain arguments)
instead of establishing the TCP connection by itself. The current
workaround is to establish SSH port forwarding asynchronously, and that
is a fragile setup that I would like to replace by something synchronous
that doesn't need to set up TCP tunnels when I can instead have "ssh -W
host:port" that talks through stdin/stdout.

I haven't seen such a feature in the 3.1 release notes - what needs to
happen that smtp can - perhaps via special syntax - be made to talk
through a command's stdio rather than through BSD sockets?

Thanks.


Best regards,

Matthias

Re: Why does postfix continue to try to deliver mail after getting a 554?

[Matthias Andree]

Am 26. Oktober 2016 12:33:48 MESZ, schrieb Julian Kippels :
>Hi,
>
>I was just wondering why my postfix was continuing to try to deliver a
>mail to another server after getting a 554 response the first time.
>Shouldn't the delivery stop right then and there and the sender be
>notified? Instead postfix tried for several days to deliver the message
>before it ultimately failed and notified the sender.
>soft_bounce is set to "no" if that has anything to do with it.
>
>Thanks,
>Julian

[x] Show logs and postconf -n output 

Re: No logs between Apr 25 - 27. What happened?

[Matthias Andree]

Am 3. Mai 2016 06:15:55 MESZ, schrieb "tswmmeejsdad ." :
>Hi All,
>
>Anyone know what I should check for to determine why logging to
>/var/log/mail stopped suddenly between Apr 25-27? I can see mail logs
>before and after those dates but nothing was logged between those
>dates.
>Mail was working fine else we would have had customers call up during
>those
>three days.
>
>Thanks.
>
>Andy

Check for:
- Syslog crashes
- Botched log rotation especially with compression vs. Signals (logrotate, 
newsyslog)
- Systemd/journal* malfunction on modern Linux 
- File system issues (skipped fsck after a crash) 
- Memory and other hw issues

Re: PATCH: Postfix / OpenSSL signal 11 on delivery from ebay

[Matthias Andree]

Am 22.03.2015 um 23:33 schrieb Viktor Dukhovni:
> Indeed external referefences would have been "U" rather "T".  So your
> build is different.  The machine OP gave me access to had the 5.6 MySQL
> client.  The builds may well be different.
> 
> The MySQL documentation:
> 
> 
> https://dev.mysql.com/doc/refman/5.5/en/source-configuration-options.html#option_cmake_with_zlib
> 
> https://dev.mysql.com/doc/refman/5.6/en/source-configuration-options.html#option_cmake_with_zlib
> 
> seems to suggest that the "system" zlib is the default, and "bundled"
> is optional.  I have no experience with FreeBSD ports or MySQL
> builds, so I have no explanation for why the 5.6 build in question
> ended up using the "bundled" zlib.
> 
> I think at this point this is up to the FreeBSD port maintainers
> (MySQL client with a nudge from Postfix) to figure out.

I consent.  To achieve that,
I have filed a Bugzilla bug with a proposed patch and assigned it to the
port maintainer.

Re: PATCH: Postfix / OpenSSL signal 11 on delivery from ebay

[Matthias Andree]

Am 22.03.2015 um 23:25 schrieb Matthias Andree:

> Nothing else relating to zlib or libz. Full poudriere 3.1.1 build log
> uploaded to
> http://people.freebsd.org/~mandree/mysql55-client-5.5.42.log.xz
> 
> There is some local /etc/make.conf stuff in the build but nothing
> obviously related to zlib.  This was a poudriere bulk build six weeks ago.

Same thing with official package, but if I look at mysql56-client (newer
version) then I get those deflate* symbols defined.

Re: PATCH: Postfix / OpenSSL signal 11 on delivery from ebay

[Matthias Andree]

Am 22.03.2015 um 22:00 schrieb Viktor Dukhovni:
> On Sun, Mar 22, 2015 at 09:34:12PM +0100, Matthias Andree wrote:
> 
>> The strange thing is, on my system the mysqlclient library appears to
>> include system zlib (10.1-RELEASE amd64):
>>
>> $ pkg which /usr/local/lib/mysql/libmysqlclient.so.18
>> /usr/local/lib/mysql/libmysqlclient.so.18 was installed by package 
>> mysql55-client-5.5.42
>> $ ldd /usr/local/lib/mysql/libmysqlclient.so.18
>> /usr/local/lib/mysql/libmysqlclient.so.18:
>>  libz.so.6 => /lib/libz.so.6 (0x801971000)
>>  libm.so.5 => /lib/libm.so.5 (0x801b87000)
>>  libc++.so.1 => /usr/lib/libc++.so.1 (0x801daf000)
>>  libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x80207)
>>  libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x80228c000)
>>  libthr.so.3 => /lib/libthr.so.3 (0x80249a000)
>>  libc.so.7 => /lib/libc.so.7 (0x80081f000)
> 
> That does not mean that there is not also a bunch of zlib code
> inside that library.
> 
> Try, "nm -D".  I get:
> 
> $ nm /usr/local/lib/mysql/libmysqlclient.so.18 | egrep 'deflate'
> 000ece80 T deflate
> 000ee2c0 T deflateBound
> 000ee510 T deflateCopy
> 000ec420 T deflateEnd
> 000ebf30 T deflateInit2_
> 00173ec5 r deflateInit2_.my_version
> 000ebed0 T deflateInit_
> 000eccc0 T deflateParams
> 000ecc30 T deflatePrime
> 000ec600 T deflateReset
> 000ec790 T deflateSetDictionary
> 000ecbb0 T deflateSetHeader
> 000ee230 T deflateTune
> 00173e90 R deflate_copyright
> 000eecb0 t deflate_fast
> 000ef4f0 t deflate_slow
> 000ee890 t deflate_stored
> 
> Which shows the functions are part of the library and not external
> references.
> 

I have tons of "T"-type symbols (yaSSL, TaoCrypt), but nothing that
contains "deflate".  So are we looking at different mysql libraries?
Version differences between 5.5 and 5.6 aside, I've dug up the poudriere
build log and figured this:

> Linking CXX shared library libmysqlclient.so
> cd /wrkdirs/usr/ports/databases/mysql55-client/work/mysql-5.5.42/libmysql && 
> /usr/local/bin/cmake -E cmake_link_script CMakeFiles/libmysql.dir/link.txt 
> --verbose=1
> /usr/bin/c++  -fPIC -O2 -pipe -march=athlon64 -fstack-protector 
> -fno-strict-aliasing -Wall -Wextra -Wformat-security -Wvla 
> -Woverloaded-virtual -Wno-unused-parameter -Wno-null-conversion 
> -Wno-unused-private-field -O2 -pipe -march=athlon64 -fstack-protector 
> -fno-strict-aliasing -DDBUG_OFF  -fstack-protector -shared 
> -Wl,-soname,libmysqlclient.so.18 -o libmysqlclient.so.18 
> CMakeFiles/libmysql.dir/libmysql_exports_file.cc.o -pthread libclientlib.a 
> ../dbug/libdbug.a ../strings/libstrings.a ../vio/libvio.a ../mysys/libmysys.a 
> -lz ../extra/yassl/libyassl.a ../extra/yassl/taocrypt/libtaocrypt.a 
> ../dbug/libdbug.a ../mysys/libmysys.a ../strings/libstrings.a -lz -lm 
> -pthread 
> cd /wrkdirs/usr/ports/databases/mysql55-client/work/mysql-5.5.42/libmysql && 
> /usr/local/bin/cmake -E cmake_symlink_library libmysqlclient.so.18 
> libmysqlclient.so.18 libmysqlclient.so

Nothing else relating to zlib or libz. Full poudriere 3.1.1 build log
uploaded to
http://people.freebsd.org/~mandree/mysql55-client-5.5.42.log.xz

There is some local /etc/make.conf stuff in the build but nothing
obviously related to zlib.  This was a poudriere bulk build six weeks ago.

Re: PATCH: Postfix / OpenSSL signal 11 on delivery from ebay

[Matthias Andree]

Am 22.03.2015 um 20:46 schrieb Wietse Venema:

> Ignore the patch. The crashes are the result of a name conflict
> with the non-system zlib implementation that is bundled with MySQL.
> The fix is to build mysql with the system zlib implementation.

The strange thing is, on my system the mysqlclient library appears to
include system zlib (10.1-RELEASE amd64):

$ pkg which /usr/local/lib/mysql/libmysqlclient.so.18
/usr/local/lib/mysql/libmysqlclient.so.18 was installed by package
mysql55-client-5.5.42
$ ldd /usr/local/lib/mysql/libmysqlclient.so.18
/usr/local/lib/mysql/libmysqlclient.so.18:
libz.so.6 => /lib/libz.so.6 (0x801971000)
libm.so.5 => /lib/libm.so.5 (0x801b87000)
libc++.so.1 => /usr/lib/libc++.so.1 (0x801daf000)
libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x80207)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x80228c000)
libthr.so.3 => /lib/libthr.so.3 (0x80249a000)
libc.so.7 => /lib/libc.so.7 (0x80081f000)

Re: Postfix / OpenSSL signal 11 on delivery from ebay

[Matthias Andree]

Am 21.03.2015 um 00:13 schrieb Wietse Venema:
> Viktor Dukhovni:
>> I am curious what:
>>
>> ldd /usr/local/lib/libssl.so.8
>>
>> reports and whether there are headers and or shared objects for
>> libz in ports?
> 
> In a FreeBSD 10.1 testvm:
> 
> # ldd -a /usr/local/lib/libssl.so.8
> /usr/local/lib/libssl.so.8:
> libcrypto.so.8 => /usr/local/lib/libcrypto.so.8 (0x801668000)
> libthr.so.3 => /lib/libthr.so.3 (0x801a6c000)
> libc.so.7 => /lib/libc.so.7 (0x80081f000)
> /usr/local/lib/libcrypto.so.8:
> libthr.so.3 => /lib/libthr.so.3 (0x801a6c000)
> libc.so.7 => /lib/libc.so.7 (0x80081f000)
> /lib/libthr.so.3:
> libc.so.7 => /lib/libc.so.7 (0x80081f000)
> 
> Fascinating: no libz dependency. See below for build options.
> 
> # uname -a
> FreeBSD freebsd101.porcupine.org 10.1-RELEASE FreeBSD 10.1-RELEASE #0 
> r274401: Tue Nov 11 21:02:49 UTC 2014 
> r...@releng1.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC  amd64
> 
> # grep OPENSSL_VERSION_NUMBER /usr/local/include/openssl/opensslv.h
> #define OPENSSL_VERSION_NUMBER  0x100010afL
> 
> This is OpenSSL 1.0.1j built from ports with default options:
> 
>   | |+[x] SHARED   build of shared libs| |
>   | |+[x] THREADS  Threading support   | |
>   | |+[ ] I386 Optimize for i386 (instead of i486+)| |
>   | |+[x] SSE2 runtime SSE2 detection  | |
>   | |+[x] ASM  optimized Assembler code| |
>   | |+[ ] PADLOCK  VIA Padlock support | |
>   | |+[x] ZLIB zlib compression support| |
>   | |+[x] SCTP SCTP protocol support   | |
>   | |+[x] SSL2 SSLv2 protocol support  | |
>   | |+[x] SSL3 SSLv3 protocol support  | |
>   ...
> 
> I don't zlib or libz in ports.

These were removed from ports c. three years ago.
libz (zlib) is only in FreeBSD's base system (/lib/libz.so.6, as of
10.1), if there are remnants of it under /usr/local, then users should
check for stale ports, or unregistered leftovers and should purge them.

Note that the FreeBSD base system's OpenSSL does not dynamically link
against libz.so either.

> I don't know how zlib is linked in, but it is relatively easy to
> disable. One may have to rm -rf /var/db/ports/security_openssl to
> reset previously-cached build options.

"make rmconfig -C /usr/ports/security/openssl"

Re: Thanks: Input requested: append_dot_mydomain default change

[Matthias Andree]

Am 24.09.2014 um 16:29 schrieb Wietse Venema:

> The implementation will probably be a compatibility_level parameter
> that is 1 for installations that pre-date this feature, that is 2
> for new installations, and that is incremented by 1 for each
> compatibility break. People who don't care can set this to 99
> and never hear a peep about compatibility breaks.

First of all, thanks for 15+ years of smooth Postfix rides.
  Whenever I needed to give an example that smooth upgrades and
compatibility are possible, Postfix is the reference project.


A few thoughts on the deployment, more of practical matter:

1 - Is changing the default - even if only applied to fresh installs - a
case for calling the first Postfix release to flip the 3.0 so people
will lift their heads to see if they're walking into pitfalls?


2 - sorry, this thought has two preceding ones that will make it look
like legalese:

2a - from talking about anonymous "change requests" in my daytime
(non systems admin) job where most people need to ask back "what is
CR088A all about?";

2b - still trusting you to get us a proper document that nicely lists
all the incompatible changes that caused this integer to be bumped:

Do you think an integer serves the purpose?  What happens if, despite
all good intention, due diligence and care, something that breaks
compatibility needs to be back ported?  Would this want to be a set of
mnemonic flags or semantic version numbers instead?


3 - is there a useful way to log warnings about unqualified domains when
they are observed and qualified in mid-flight, so that people have
something to watch for before flipping the switch?  It seems there
already is, check_{sender,recipient}_access + WARN action + regexp map -
so canonical information how to enable this ahead of time already now
might help smooth out the migration even more.

Re: localhost.com

[Matthias Andree]

Am 28.09.2014 um 08:23 schrieb Ruben Safir:
>>
>> That will work. Another solution is setting append_dot_mydomain=no,
>> so that user@localhost will become u...@localhost.com.
>>
> 
> 
> 
> 
> Yes - I am confused by this a little bit.  Why would postfix want to add
> a dot com to any outgoing email?

Because it tries to make e-mail messaging just work for those
who choose to abstain from reading documentation or set up their systems
in ways that are useful for e-mail.

Re: localhost.com

[Matthias Andree]

Am 21.09.2014 um 11:11 schrieb Ruben Safir:

> Ah - thank you.  I thought you ment that, but I was being dense.
> When I ran fetchmail through verbose I saw that it connected to
> localhost on port 25 so I figured that maybe postfix was attaching a
> .com to that.  I just wanted to make double sure that I understood what
> I thought you said was exactly what you ment.

[...]

> :)  well, we people from brooklyn sometimes need to be told twice.

Sorry I'll be blunt but try to comply with your request,
I'll repeat one thing from another message in this thread:

This was written by li...@rhsoft.net:
> it it because you have to mention you real config and logs
> if you need help (postconf -n nad logs showing the problem)

And this is also what caused you spinning in circles without making
headway towards a solution.  Next time you have Postfix trouble, provide
the output of "postconf -n". Unadulterated and without being asked for
it please, saves at least two messages for all of us. :-)

Re: *canonical_classes not behaving as expected with local mail submission

[Matthias Andree]

Am 01.09.2014 um 06:57 schrieb Valdemar Jakobsen:
> Dear Postfix-Users,
> 
> I’m using sender_canonical_maps to ensure that my envelope addresses
> comply with SPF policies and also allow for a valid bounce address in
> the event of non-delivery.
> 
> My gateway mail servers are configured using sender_canonical_maps with
> "sender_canonical_classes = envelope_sender” and this works as expected
> for internet mail submission (i.e. smtpd:25), but not for local
> submission on the gateway mail server.

You will need to provide your master.cf and information on how "local
submission" works in your setup, and logging for a "failing" message,
and possibly constrast it to your "working" smtpd-on-port-25 submission.

master.cf setups often override some of the smtpd settings for local
submission ports in order to require and permit authentication for
relay, and this might override your canonical mapping.

Re: Postfix removes content from a file

[Matthias Andree]

Am 07.08.2014 um 19:23 schrieb Ramesh:
> It is not a problem with quotes, all these days it was working fine,
> since yesterday receiving messages without content.

1. you showed a shell command that had broken quoting,
and apparently from a shell that does not properly complain about mixing
quotes or unterminated commands

2. Your mail surely was not part of Postfix

3. so why do you need to accuse the Postfix server if your misuse your
shell or some system utility, or that one goofs up?

> I don't know where went wrong in the server.

It did not. It went wrong before it hit the server, as the kind
anonymous li...@rhsoft.net user already told you.


And please, for this list, use Internet-style quoting, do not send HTML,
and do not put your material on top of a full-quote.

Re: Postfix Dovecot Maildir

[Matthias Andree]

Am 28.07.2014 um 18:43 schrieb nobody73:
> Sending mail to u...@domain.of.mine i get a positive response from
> mail logs ...
> 
> status=sent (delivered to maildir)
> 
> these are permissions for mail spool:
> 
> ls -la /var/mail/
> total 12K
> drwxrwsrwx  2 root  mail 4.0K Jul 27 22:41 .
> drwxr-xr-x 12 root  root 4.0K Jul 13 01:36 ..
> -rw---  1 admin mail0 Jul 27 14:53 admin
> -rw---  1 root  mail 3.7K Jul 27 22:41 root
> 
> and
> 
> home_mailbox = Maildir/
> mailbox_command =

These are inconsistent.  Read up what home_mailbox means.

> ... but connecting to both POP and IMAP by thunderbird don't find any
> delivered mail.

You will have to configure and check consistent locations.  /var/mail/
is not a maildir, and you haven't shown where Dovecot looks - either
tell Postfix to deliver there, or tell Dovecot (off-topic here) to look
for where Postfix delivers.

Re: Berkeley DB6 and Postfix

[Matthias Andree]

Am 16.05.2014 01:27, schrieb Jerry:

> Using version 6 on a FreeBSD machine is not really a necessity anyway. All I
> wanted to do was eliminate having multiple version numbers of the same
> program on my machine. In any case, unless the FreeBSD port maintainer
> chooses to modify the Postfix port to allow it to compile, it doesn't make
> any difference what license Berkeley 6 is under.

I wonder what /practical/ compelling advantages DB6 has over DB5 (the
FreeBSD db5 port actually uses that last released DB5 version, 5.3),
as long as you leave out all the licensing advocacy.

Re: Berkeley DB6 and Postfix

[Matthias Andree]

Am 12.05.2014 00:18, schrieb Jerry:
> I have been using Postfix on an old FreeBSD server for years without
> problems. I just updated to a new machine and installed the latest version
> of FreeBSD along with Berkeley DB6. I wanted to install the newest version
> of Postfix available in the ports system, "postfix-current" version
> 2.12-20140507.
> 
> The installation halts immediately with this error message:
> 
> ===>  postfix-current-2.12.20140507,4 cannot install: does not work with 
> Berkeley DB version 6 (6 not supported).
> 
> Is this correct or am I doing something terribly wrong? Version "6" has
> been out for quite some time now and I would have thought that Postfix
> would have supported it.
> 

Double check if the DB6 license is adequate for your needs,
and if it is compatible with Postfix at all.

Oracle BerkeleyDB version 6, unlike its predecessor versions, uses the
Affero GNU Public License (no longer the SleepyCat license), so you must
open-source your components even if only used as a service, but not
distributed. Check the full license text for all the details.

Re: Messages still in queue even after 5xx reply

[Matthias Andree]

Am 16.11.2013 11:21, schrieb Erik Grøtnes:
> Hi.
> 
> In my postfix queue I can see messages with return code 5xx which are
> still in queue for delivery.
> 
> I find this strange, as the RFC 2821 states that codes starting with 5xx
> is a permanent failure, and “The SMTP client is discouraged from
> repeating the exact request”.
> 
>  
> 
> Is this default behavior, or is this something I have done in my config
> by mistake?

Check if soft_bounce is "yes". I seem to recall that it would make 454
from the 554, but I may be recalling wrongly.

Anyways, see if

postconf -e soft_bounce=no
postfix reload
postfix flush

helps.

Re: Is it time for 2.x.y -> x.y?

[Matthias Andree]

Am 01.06.2013 14:34, schrieb Patrick Ben Koetter:

> I wouldn't go as far to say that if they don't understand major.minor.patch
> they shouldn't be using the software at all. Reminding how I started and all
> the stuff I had to learn, I'd find that pose rather arrogant and not helpful
> in becoming a better admin.

I don't mean "understand", but "understand when it has been explained".

> If there are some, who have trouble finding the right version maybe some
> additional words of explanation or stylistic enhancements (the fancy stuff...)
> will do the trick.

I don't object to better markup, explanations, or such, but I see no
reason to change the versioning.

Re: Is it time for 2.x.y -> x.y?

[Matthias Andree]

Am 31.05.2013 22:56, schrieb Wietse Venema:
> After the confusion that Postfix 2.10 is not Postfix 2.1, maybe it
> is time to change the release numbering scheme.

Glad you are asking.

No, it is not the time to join in brainless version numbering races.

Tell people those are independent numbers with a particular meaning
(major, minor, patch/bugfixlevel), link to a "how to read Postfix's
version numbers" document from 1. the download page, 2. from the FAQ's
front page, 3. from Postfix's web front page, and, as proposed in this
thread, 4. from postconf and possibly 5. postfix manual pages; and if
that does not suffice, consider it an intelligence test as to who should
_not_ be operating a mail transfer agent because he or she cannot handle
the complexities.

Possibly add "2.1 -> 2.2 -> 2.9 -> 2.10 -> future 2.11" figure so
people see quickly that 2.10 was newer than 2.9 and 2.1...

> or we could do it like Sun. After releasing Solaris 2.0 .. 2.6,
> they changed the numbering scheme with Solaris 7 which was released
> way back in 1998. Nowadays, many software distributions change the
> major release number frequently, if not every time.

Is there a _technical_ reason (undereducation on a part of the users
does not count) to follow Google's useless race of versioning that makes
major version numbers pointless (oh, and Google does have four-component
version numbering..., and Mozilla stuck to three-component in spite of
joining the race)?

Why sacrifice the semantic value of "if major version changes, check for
major incompatibilities"?  What do we gain?

> If we were to change the release numbering scheme like this with
> Postfix then we would immediately be free from the pain of getting
> sites to adopt Postfix 3.0, because they would no longer expect the
> pain of transitioning from Python 2->3, from perl 5->6 and the like.
> The next Postfix release would be 11.0, so 3.x would never happen.

My vote is "keep the versioning system", and explain it.  Else it will
take ages until distributions adopt the new system, causing two or so
years of even more confusion.

And I must say that I have always appreciated the excellent
compatibility and release documentation Postfix has provided - thanks
for your keeping this up for ever since the first formal release,
I value such consistency over changing version numbering schemes to
accommodate a few inattentive people.

Re: qmail forward to postfix on the same machine ?

[Matthias Andree]

Am 21.03.2013 13:09, schrieb Frank Bonnet:
> Hello
> 
> I'm in trouble with an old Qmail server that runs on
> an also old server.
> 
> The problem is I cannot modify the existing configuration
> of this machine because of inhouse developped applications
> that use qmail.
> 
> Qmail ( which i know very few ) seem a bit autistic when talking
> to non FQDN distants servers or with MX misconfigured.
> 
> my idea is to add a postfix instance on this machine which will
> send emails to the Internet.
> 
> In my plan Qmail will inject all outgoing SMTP traffic into Postfix
> instance that will send it outside .
> 
> it that config I could tweak postfix as I want to manage outgoing
> emails.
> 
> The server is mainly used to send daily newsletters
> 
> Anyone did this ?
> 
> Is it possible ?

There is one caveat, though: qmail-send will disassemble multi-recipient
posts, i. e. you will get one Postfix message and queue ID per recipient
- and Postfix has some VERP support (Mailman, for instance, uses it.)

If you can somehow manage to inject outgoing mail directly into Postfix,
so that you can bypass qmail-send, that may help quite a bit.  If your
software talks QMQP for injection into qmail for sending outbound mail,
you can make Postfix provide a QMQPd.

abusive language by Reindl (was: generally use of mailing-lists)

[Matthias Andree]

Am 13.01.2013 22:01, schrieb Reindl Harald:
> would brainded idiots like "Matthias Andree" stop to post OFF-LIST
> their bullshit while they are missing that i was NOT the one
> who replied off-list and started this trhead?

Sorry for the noise, and apologies for confusing two persons.
One has apparently learned their lesson, the other jumped to defend the
trespasser and has now resorted to insults rather than limiting himself
to pointing out the misaddressing.

Make up your own mind... but don't respond to the list.
Reply-To: is set, I hope the list software does not replace it.

Matthias

Re: Learning how to respecth REPLY-TO headers

[Matthias Andree]

Am 11.01.2013 15:33, schrieb Robert Moskowitz:
> 
> On 01/11/2013 09:07 AM, Wietse Venema wrote:
>> Robert, please configure your mail reader to respect the REPLY-TO
>> header. I have asked you this before, and I think I will ignore
>> your email until you play by the same rules as everyone else.
> 
> Sorry about that last transmission.
> 
> Your request would be reasonable if every list I am on worked the same way.
> 
> Some I have to reply to all to get just the list. Some I have to respond
> to sender. Some I have to close the mail and respond to sender from the
> message list. Some require me to edit the reply list and that also
> varies. It is very inconsistant. It takes dilligence on my part, and I
> will freely admit that I am not consistant either. Perhaps ties into my
> various life challenges.
> 
> I WILL work more at paying attention to what works here.

Your headers reveal you are using Thunderbird; it can't be that hard to
click "List reply" or whatever the button inscription translates to in
your locale.  It works for the Postfix list.

Re: postfix apprently uses mboxo format with local(8), which irrecoverably corrupts mail

[Matthias Andree]

Am 29.10.2012 22:05, schrieb Christoph Anton Mitterer:
> Hey Matthias.
> 
> On Mon, 2012-10-29 at 21:45 +0100, Matthias Andree wrote:
>> Well, if you'd looked at the date of your sources, you'd have known that
>> others have failed establishing alternatives to what DJB or Rahul Dhesi
>> or whoever dubbed "mboxo" in nearly two decades.
> Well there are several projects out there that actually use
> alternatives, e.g. dovecot, mutt, getmail, KMail ... and I guess these
> are not the only ones.

(I am aware of Wietse's reply to the message I am quoting.)

Let us not speak of the things that do not even know how to validate or
manage X.509 certificates properly.

>> From_ line stuffing has been known for a long time, and given MIME, it
>> is always possible to encode a message such that it can be stored in a
>> mboxo database without loss of information. MIME quoted-printable has
>> been invented roughly two decades ago.
>> I seem to recall that I had proposed to re-encode From_ lines to MIME
>> quoted/printable years ago (turning them into =46rom_ lines or
>> thereabouts),

> Well quoted printable encoding is of course a way around this, but
> similarly as you have no guarantee that a client/tool
> understands/expects e.g. mboxrd, you have no guarantee that a mail that
> postfix receives was composed by a client that does this quoting, right?

Either you choose the argument in your favour or contradiction - but use
it consistently.  Meaning that: Either you make assumptions on the
client software's capabilities (regardless of whether you require a
particular handling of From_-stuffing, or MIME), or you do not.

>> That is not going to happen on systems outside your domain of control.
>> Face it.

> Resignation is probably not the way to change the world! ;-)

No, but reinventing the wheel whilst ignoring existing solutions, or
trying guerilla standardization, are no such ways either.

As stated earlier, there is no single established mbox flavour, and has
not been for nearly two decades.

Acknowledging there is no consensus, every hard-wired change between
mbox flavours will please one group and inconvenience another group.

Maildir was designed to address message-format compatibility issues like
the one you are complaining about.

> Anyway, would you know any technical or compatibility reasons that
> prevent local(8) from using mboxrd?

Incompatibility with documentation - such as local(8) - and existing
Postfix practice of the past sixteen-or-so years.

The delivery agent is the right place to deal with delivery issues such
as output formats - especially in situations that the sender should not
need to be aware of - and the proper output format to address your
problems has already been invented, Maildir.

Now, if you are asking for reasons why local(8) is prevented from using
mboxrd, or from switching to mboxrd by default, you will have to allow
the question held up against you what technical reason there is NOT to
use Maildir.  You have not answered that one, either on the
fetchmail-users list, nor on the postfix-users list, yet.

Re: postfix apprently uses mboxo format with local(8), which irrecoverably corrupts mail

[Matthias Andree]

Am 29.10.2012 00:46, schrieb Christoph Anton Mitterer:

> I just stumbled across this issue with mboxo recently and it seems that
> most users are not familiar with it (or that there are actually several
> mbox formats).

Well, if you'd looked at the date of your sources, you'd have known that
others have failed establishing alternatives to what DJB or Rahul Dhesi
or whoever dubbed "mboxo" in nearly two decades.

The whole signature part of the discussion is a red herring.
 From_ line stuffing has been known for a long time, and given MIME, it
is always possible to encode a message such that it can be stored in a
mboxo database without loss of information. MIME quoted-printable has
been invented roughly two decades ago.


I seem to recall that I had proposed to re-encode From_ lines to MIME
quoted/printable years ago (turning them into =46rom_ lines or
thereabouts), possibly not directly in Wietse's direction - but that is
more than a decade old, too:



I wonder if there is pertinent code in the 8BITMIME support corner that
could be leveraged to avoid From_ stuffing iff (the message is already
in MIME format OR a particular future local(8) option is enabled).

> I think especially new users with simple setups may often use local(8),
> because with local users you don't need "complicated" setup with virtual
> mailboxes and authentication...
> And especially for them, I think it would be good goal when all systems
> could move away from mboxo. :)

That is not going to happen on systems outside your domain of control.
Face it.

Re: (no subject)

[Matthias Andree]

(note I've manually directed replies to the list - I do not desire
personal replies)

Am 09.01.2012 06:23, schrieb Ashok Kumar J:
>  I would like to know about any compression technology implemented and
> used in the postfix mail queue.

There is none.  As to the record format of the queue files, please
consult the sources - that's what open source software offers as its
advantage.

Re: Postfix talking smtp through stdio command?

[Matthias Andree]

Am 06.09.2011 19:30, schrieb Ansgar Wiechers:
> On 2011-09-06 Matthias Andree wrote:
>> I am in a situation where I would like to achieve either of these
>> solutions:
>>
>> Alternative A:
>>
>> - have Postfix's smtp client talk through a command via stdin/stdout
>> (instead of a TCP stream).
>>
>> That command would be ssh -W mailhub:25, with a user-specified
>> password and possibly some sort of credentials cache (like ssh-agent).
>>
>> - Ideally, I would be able to pass relevant environment variables such
>> as SSH_AUTH_SOCK to the SMTP client somehow, and Postfix's smtp client
>> would run under my own unprivileged user ID if possible (else I need
>> to find a proxy for ssh-agent, too, because it checks the peer user
>> ID).
>>
>> - What I can do, but dislike because it's unreliable and consequently
>> insecure, is: set up a regular ssh tunnel (with local listening TCP
>> stream socket) with "-L" local forwarding and redirect Postfix there.
> 
> What makes you believe that an SSH tunnel were any less reliable than
> "ssh -W"?

The tight coupling (on client side) through stdio is what matters here.
 If I put localhost:1234 as my relayhost and someone else grabs that
port, my mail is possibly gone if it's a different SMTP server rather
than the hoped-for SSH tunnel.  Not acceptable.

Re: Postfix talking smtp through stdio command?

[Matthias Andree]

Am 07.09.2011 19:13, schrieb Bastian Blank:
> On Tue, Sep 06, 2011 at 08:59:20PM +0200, Matthias Andree wrote:
>>> Can you describe the problem instead of the solution? There may be
>>> other solutions than the ones you have in mind.
>> The problem is this:
>> - I *can* (and am permitted to) connect to a computer in the same LAN as
>> the SMTP server by SSH.
> 
> One quiet old solution is UUCP-over-ssh. It is reliable, batches mail in
> both direction and does not need much ressources.

There's an idea, and might actually work given the destination
environment.  I know that I can make Postfix talk to uux, I don't
remember having used uucico over ssh, but I'll see if that's feasible.
(The other side runs on FreeBSD, so I think a Unixish solution is
appealing enough to have the admins consider it. :))

Re: Postfix talking smtp through stdio command?

[Matthias Andree]

Am 07.09.2011 19:05, schrieb Jeroen Geilman:
> On 2011-09-07 00:55, Matthias Andree wrote:
>> The firewall block is deliberate.
> 
> Then I suggest you talk to some people and tell them you need email
> access...
> I find it rather quaint that you would be trying to set up SMTP
> connectivity on a system where this has - as you say - been expressly
> forbidden.

These people allow me to use SSH tunnels, but their Postfix doesn't talk
AUTH.  If someone is aware of an SASL implementation for Postfix that
authenticates users through SSH public keys in their
~SOMEUSER/.ssh/authorized_keys files, I'm all ears. :)

Re: Postfix talking smtp through stdio command?

[Matthias Andree]

Am 06.09.2011 22:41, schrieb /dev/rob0:
> On Tuesday 06 September 2011 13:59:20 Matthias Andree wrote:
>> Am 06.09.2011 19:30, schrieb Wietse Venema:
>>> Matthias Andree:
>>>> Greetings,
>>>>
>>>> I am in a situation where I would like to achieve either of
>>>> these solutions:
>>>>
>>>> Alternative A:
>>>>
>>>> - have Postfix's smtp client talk through a command via
>>>> stdin/stdout (instead of a TCP stream).
>>>
>>> Can you describe the problem instead of the solution? There may
>>> be other solutions than the ones you have in mind.
>>
>> The problem is this:
>>
>> - I cannot connect to the remote SMTP relayhost via plain TCP, it's
>> firewalled on all ports.
>>
>> - The relayhost does not offer submission STARTTLS or SSL-wrapped
>> legacy ports.
>>
>> - I *can* (and am permitted to) connect to a computer in the same
>> LAN as the SMTP server by SSH.
> 
> If you have root on this internal machine, or if you can persuade the 
> administrator to allow it, you can set up a p2p-mode openvpn between 
> your host and the one you SSH to. This can punch through closed 
> firewalls, because each endpoint is trying to send packets to the same 
> UDP port on the other. A stateful firewall will typically assume that 
> the outside host is replying to the LAN host.

Good plan, but neither root nor any chance to persuade $admin.

The firewall block is deliberate.  I've set up OpenVPN more than once,
so that would've been easy. 8-)

Re: Postfix talking smtp through stdio command?

[Matthias Andree]

Am 06.09.2011 22:04, schrieb Peter Blair:

> You could hack up a local perl SMTP listener on you local system,
> which when it receives all of the SMTP back and forth, and then the
> ".", it executes a SSH subshell, formatting the recipient/sender etc
> via the gateway, and pipes the DATA portion over its FH.

This "local listener" is what I already have (it's not ssh that's
unreliable, but the overall design that's fragile), and it is exactly
what I'm trying to avoid.

I want a tighter, synchronous, coupling between the local SMTP client
and the remote SMTP server.  Nothing that relies on the ssh tunnel being
up in the exact moment when Postfix/smtp chooses it wants to relay a
message because that I cannot guarantee.

Re: Postfix talking smtp through stdio command?

[Matthias Andree]

Am 06.09.2011 19:30, schrieb Wietse Venema:
> Matthias Andree:
>> Greetings,
>>
>> I am in a situation where I would like to achieve either of these solutions:
>>
>> Alternative A:
>>
>> - have Postfix's smtp client talk through a command via stdin/stdout
>> (instead of a TCP stream).
> 
> Can you describe the problem instead of the solution? There may be
> other solutions than the ones you have in mind.

The problem is this:

- I cannot connect to the remote SMTP relayhost via plain TCP, it's
firewalled on all ports.

- The relayhost does not offer submission STARTTLS or SSL-wrapped legacy
ports.

- I *can* (and am permitted to) connect to a computer in the same LAN as
the SMTP server by SSH.

- The authentication infrastructure only supports SSH-2 public/private
key authentication.


The current solution is (options are: -f = background, -M = master, so
as to keep the command alive, -N = no command, -L = port forward)

ssh -f -M -N -L :mailhub.example.org:25 sshgate.example.org

This particular tunnel I'd like to get rid of.  1) It gets stuck across
a computer's suspend (I suspect that's a misconfiguration of the
firewall and it should die some 2:19 hours after an attempt to send mail
because the Linux kernel I'm using would finally consider the TCP stream
dead); 2) if for some reason it's not my own SSH process listening on
port , I'm in trouble.


Arguably this should be fixed with authenticated submission (port 587),
possibly with certificates; but it has not happened in a year although
people promised to look into it.

Postfix talking smtp through stdio command?

[Matthias Andree]

Greetings,

I am in a situation where I would like to achieve either of these solutions:

Alternative A:

- have Postfix's smtp client talk through a command via stdin/stdout
(instead of a TCP stream).

That command would be ssh -W mailhub:25, with a user-specified password
and possibly some sort of credentials cache (like ssh-agent).


- Ideally, I would be able to pass relevant environment variables such
as SSH_AUTH_SOCK to the SMTP client somehow, and Postfix's smtp client
would run under my own unprivileged user ID if possible (else I need to
find a proxy for ssh-agent, too, because it checks the peer user ID).


- What I can do, but dislike because it's unreliable and consequently
insecure, is: set up a regular ssh tunnel (with local listening TCP
stream socket) with "-L" local forwarding and redirect Postfix there.


The administrative difficulty behind this is that no SMTP AUTH is in place.


Alternative B:

Is anyone aware of SASL setups to authenticate against
.ssh/authorized_keys on the server side and somehow have the client have
the ssh-agent sign some server-side request?



However Postfix runs on either end, and I'm not too optimistic there's a
whole lot of difference in difficulty level on the client-side.  I
currently expect getting the SSH credentials into the smtp client is
somewhat hard, and a shared difficulty between these approaches.

Is either of this possible, even partially?

Thanks.

Re: With soft_bounce set to no, we are seeing a lot of send failures that look like they should be permanent 554's being handled as temporary.

[Matthias Andree]

Am 20.07.2011 05:15, schrieb Michael Orlitzky:

> And a trickier one:
> 
>   * smtp_dns_resolver_options = res_defnames, in postfix <= 2.8

That would be "< 2.8".

> Append the current domain name to single-component names (those
> that do not contain a "." character). This can produce incorrect
> results, and is the hard-coded behavior prior to Postfix 2.8.

Mind you there was a massive related bug in GNU glibc and eglibc that
caused name lookups to fail without glibc ever having sent a DNS query
when res_defnames was cleared for one-component names.

This was reported against the upstream and at least Ubuntu and openSUSE,
and it is fixed in the upstream glibc repository, but I'm not aware
which Linux distros have actually gone for a stable release update.

See https://bugs.launchpad.net/ubuntu/natty/+source/postfix/+bug/777855
it also has links to the upstream and SUSE reports and the upstream
patch to (e)glibc.

Re: reinjection via unix socket

[Matthias Andree]

Am 19.07.2011 17:02, schrieb Lars Täuber:
> Hi Wietse,
> 
> the unix socket can't be used by other users than root or postfix.
> Is there a way to configure ownership and/or permissions for the socket?
> 
> I thought under Linux the filesystem permissions reflect the permissions to
> the unix socket.
> 
> Here is my config and the socket:
> master.cf:
> backdoor
>   unix  n   -   n   -   3   smtpd
> 
> # ls -l /var/spool/postfix/public/backdoor 
> srw-rw-rw- 1 postfix postdrop 0 2011-07-19 14:15 
> /var/spool/postfix/public/backdoor
> # sudo -u dspam /usr/bin/socat - 
> UNIX-CONNECT:/var/spool/postfix/public/backdoor
> 2011/07/19 16:53:44 socat[23143] E connect(3, AF=1 
> "/var/spool/postfix/public/backdoor", 36): Permission denied
> 
> Am I doing something wrong?

Don't forget about the directory permissions. The dspam user needs
execute permission for all containing directories, i. e.
/var/spool/postfix/public, /var/spool/postfix, /var/spool, /var, and /.

I supposed your dspam system user probably doesn't have access to the
/var/spool/postfix/public directory (1), which check.

If that's indeed the situation, review the security implications; you
can either use ACLs to permit the dspam user execute permission fix that
up (if supported and enabled on your /var filesystem), or you can
consider making dspam a member of the postdrop group.


(1) mine looks like this on Postfix 2.8:

drwx--s--- 2 postfix postdrop 4096 2011-07-19 00:44
/var/spool/postfix/public

Re: AUTH LOGIN without 250 AUTH?

[Matthias Andree]

Am 08.07.2011 13:30, schrieb Zólyomi Szabolcs:
> Dear all,
>   
> I am a newbie here and in postfix too. After searching the web and browsing
> some forums, I still haven't got a solution for a problem I struggle with.
> If you have the time, please help me.
> 
> Our corporate mail server (mail.ourcompany.hu) is operated by an external
> provider. I am trying to set up a postfix relay server in front of it with
> the following components: Linux CentOS 5.5 with actual patches + postfix
> 2.3.3 + cyrus SASL 2.1.22
> The goal is to enable some internal systems sending mails without
> authenticating themselves at mail.ourcompany.hu

> Jul  6 14:53:16 ourcompanydmz postfix/smtp[27517]: >
> mail.ourcompany.hu[xx.xxx.xxx.xx]: HELO ufsz.ourcompany.hu

Why do you send HELO?  Fix that: You need to send EHLO if you want an
AUTH offering.

Re: Port 587 Per RFC 4409

[Matthias Andree]

Am 21.06.2011 16:26, schrieb Carlos Mennens:
> On Tue, Jun 21, 2011 at 10:23 AM, Reindl Harald  
> wrote:
>> please provide configuration and NOT netstat
>>
>> [root@testserver:/buildserver/autotest/parts/ffmpeg]$ cat 
>> /etc/postfix/master.cf | grep submission
>> submission  inet  n   -   n   -   20  smtpd -o 
>> smtpd_client_connection_count_limit=15 -o
>> smtpd_sasl_auth_enable=yes -o smtpd_delay_reject=yes -o 
>> smtpd_client_restrictions=permit_sasl_authenticated,reject
> 
> Sorry I've been told not to provide this unless specifically asked for:
> 
> [root@mail ~]# cat /etc/postfix/master.cf | grep submission
> #submission inet n   -   n   -   -   smtpd
> 
> That's all I got...

Meaning that you have DISABLED this service (mind the # character!).

Re: Milter does not process from postfix 2.7.1-1 (Debian Squeeze)

[Matthias Andree]

> JKL:

>> The server, with the three milters, was running perfectly well until a
>> few weeks ago.  All milters sockets are inside a place where Debian
>> postfix can get to.

Am 15.06.2011 21:27, schrieb Wietse Venema:

> When something stops working, then something has changed. You need
> to find out what has changed. Postfix does not change spontaneously.

For Debian and derivatives in particular: the package management tools
(apt* and dpkg) log their actions, so people can check /var/log/apt* and
/var/log/dpkg* and possibly sub-directories.

Re: Cyrus SASL Auth

[Matthias Andree]

Am 30.05.2011 13:49, schrieb M. Rodrigo Monteiro:
> Hi!
> 
> I'm trying to setup an SMTP Gateway, with Postfix authenticating in Cyrus 
> SASL.
> 
> # postconf mail_version
> mail_version = 2.8.2
> 
> # postconf -a
> cyrus
> dovecot
> 
> # /usr/local/cyrus-sasl/sbin/saslauthd -l -n 10 -a rimap -O imap_server
> 
> # /usr/local/cyrus-sasl/sbin/testsaslauthd -u
> rodrigo.monteiro@mydmoain -p password
> 0: OK "Success."
> 
> ### main.cf ###
> smtpd_sasl_auth_enable = yes
> smtpd_sasl_security_options = noanonymous
> smtpd_sasl_local_domain =
> broken_sasl_auth_clients = yes
> smtpd_sasl_path = smtpd
> cyrus_sasl_config_path = /usr/lib/sasl2/smtpd.conf
> smtp_sasl_path = /usr/lib/sasl2/smtpd.conf
> #
> 
> # cat /usr/lib/sasl2/smtpd.conf
> pwcheck_method: saslauthd
> mech_list: PLAIN LOGIN
> saslauthd_path: /usr/local/cyrus-sasl/var/mux
> 
> ### maillog ###
> May 29 18:42:01 sec56 postfix/smtpd[22830]: warning: SASL
> authentication problem: unable to open Berkeley db /etc/sasldb2: No
> such file or directory
> May 29 18:42:01 sec56 postfix/smtpd[22830]: warning: SASL
> authentication problem: unable to open Berkeley db /etc/sasldb2: No
> such file or directory
> May 29 18:42:01 sec56 postfix/smtpd[22830]: warning: SASL
> authentication failure: Password verification failed
> ##
> 
> What am I missing? Why Postfix is trying to use /etc/sasldb2 instead
> of saslauthd?

The cyrus_sasl_config_path expects a directory, you've specified a file.
Check and correct that. Note that a particular Cyrus version is required
for this to work, check man 5 postconf (or man -s 5 postconf).

Is Postfix reading the configuration the way you mean it? Check the
output of "postconf -n".

Is smtpd run in a chroot? Check master.cf.

After all that: does your Cyrus installation really read its
configuration from /usr/lib/sasl2, or rather from /usr/local/lib/sasl2?
 You haven't quoted relevant configuration to that extent.  Try setting
a relative symlink:
ln -s ../../lib/sasl2 /usr/local/lib (be sure to update the chroot if
you use one!)

Re: postfix not happy with libmysqlclient.so.18

[Matthias Andree]

Also, be sure to double check you don't have a different Postfix
installation in different paths, possibly with different PREFIX from
past experiments.

-- 
Matthias Andree

Re: postfix not happy with libmysqlclient.so.18

[Matthias Andree]

Am 21.05.2011 21:33, schrieb Len Conrad:
> 8.2-RELEASE FreeBSD
> 
> make && install done here:
> 
> cat /usr/ports/mail/postfix-current/distinfo 
> SHA256 (postfix/postfix-2.9-20110501.tar.gz) = 
> 5789269f34fa152e39a70af3077f3ce4bc9c4e52fc67bb50a42e5d245ee1da3b
> SIZE (postfix/postfix-2.9-20110501.tar.gz) = 3671046
> 
> 
> pkg_info shows:
> 
> mysql-client-5.5.11 Multithreaded SQL database (client)
> mysql-server-5.5.9  Multithreaded SQL database (server)
> postfix-current-2.9.20110228,4 A secure alternative to widely-used Sendmail
> 
> postconf
> /libexec/ld-elf.so.1: Shared object "libmysqlclient.so.16" not found, 
> required by "postconf"
> 
> locate libmysqlclient
> /usr/local/lib/mysql/libmysqlclient.a
> /usr/local/lib/mysql/libmysqlclient.so
> /usr/local/lib/mysql/libmysqlclient.so.18
> /usr/local/lib/mysql/libmysqlclient_r.a
> /usr/local/lib/mysql/libmysqlclient_r.so
> /usr/local/lib/mysql/libmysqlclient_r.so.18

On FreeBSD, use one of the established ports management tools, notably,
portmaster, or portupgrade. These ensure that your dependent ports are
up to date, too.  Also note that the locate database can be out of date
and is not an authoritative reflection of what's really on your disks.
To be sure, check the output of:

find /usr/local -name libmysqlclient\*

For shared library issues, running "ldconfig" can also help.

-- 
Matthias Andree

Re: localhost pitfall in resolver/solving "Host or domain name not found. Name service error for name=localhost type=A: Host not found" (also type=AAAA)

[Matthias Andree]

Am 05.05.2011 20:46, schrieb Victor Duchovni:
> On Thu, May 05, 2011 at 08:37:01PM +0200, Matthias Andree wrote:
> 
>> I had checked the Postfix 2.8 release notes immediately, but they bore
>> no references to this particular HISTORY entry:
> 
> It is in the 2.8 release notes:
> 
> Major changes - dns lookup
> --
> 
> [Incompat 20100827] The Postfix SMTP client no longer appends the
> local domain when looking up a DNS name without ".".  Specify
> "smtp_dns_resolver_options = res_defnames" to get the old behavior,
> which may produce unexpected results.
> 

Ouch.  I'd checked the release announcement but missed the longer actual
RELEASE_NOTES.  My bad, but perhaps it was still good for something
(like the glibc resolver).

Re: localhost pitfall in resolver/solving "Host or domain name not found. Name service error for name=localhost type=A: Host not found" (also type=AAAA)

[Matthias Andree]

Am 05.05.2011 18:23, schrieb Victor Duchovni:

> You know exactly what you mean when you use "[localhost]" as a nexthop,
> why not say so? What's the point of jumping through a pile of indirection
> and shared libraries just to arrive at an address that every administrator
> knows in advance. In fact, localhost may resolve to both "::1" and
> "127.0.0.1", but only one or other is typically correct. 

> So I say that this particular "indirection" is counter-productive.
> The IPv4 or IPv6 address of localhost is not changing any time soon,
> and you just complicate things unnecessarily by using the name.

Victor,

Thanks, that reasoning makes sense.

Still it was quite irritating that a Postfix upgrade "broke" my system
(quoted because it didn't break but suffered from a resolver bug that
Wieste probably hadn't seen on FreeBSD), this hadn't happened in a dozen
years.

I had checked the Postfix 2.8 release notes immediately, but they bore
no references to this particular HISTORY entry:

20100827
...
Bugfix: the Postfix SMTP client no longer appends the local
domain when looking up a DNS name without ".".  Specify
"smtp_dns_resolver_options = res_defnames" to get the old
behavior, which can produce unexpected results. Files:
smtp/smtp.c, smtp/smtp_params.c, smtp/smtp_addr.c.

Can this retroactively be put into the 2.8 release notes as
[Incompatible Bugfix ...] entry on the websites and for 2.8.3+ releases?

Best regards,
Matthias

Re: localhost pitfall in resolver/solving "Host or domain name not found. Name service error for name=localhost type=A: Host not found" (also type=AAAA)

[Matthias Andree]

Am 05.05.2011 17:33, schrieb Victor Duchovni:
> On Thu, May 05, 2011 at 03:49:35PM +0200, Matthias Andree wrote:
> 
>> Executive summary:
>>
>> We are facing a massive bug in the GNU glibc 2.11 and eglibc 2.13
>> resolvers which fails to even attempt a query for a name without dots if
>> RES_DEFNAMES is unset.  FreeBSD 8.2, DragonflyBSD 2.10 and Solaris 10
>> are unaffected.
> 
> Do NOT use "[localhost]" as an SMTP nexthop. I always use "[127.0.0.1]".
> If IPv6 works well for you, you can use "[::1]".

Hi Victor,

Why do you recommend so, now that Postfix strips RES_DEFNAMES from
_res.options by default?  This resolver bug aside :)

(It used to work before the stripping, probably because I take care that
localhost resolves either properly to 127.0.0.1/::1 or to NXDOMAIN in
the domains I list in /etc/resolv.conf's "search" or "domain".)

Best regards,
Matthias

Re: localhost pitfall in resolver/solving "Host or domain name not found. Name service error for name=localhost type=A: Host not found" (also type=AAAA)

[Matthias Andree]

t;, 27,
MSG_NOSIGNAL) = 27
res search result: 43

We get a result, as expected from resolver source code.
Now, leave RES_DEFNAMES set (again, Linux):

$ strace -e send,recv ./try-resolv localhost 0x800c1
default _res.options = 802C1
strip flags= 282
stripped _res.options = 80041
forced _res.options = 800C1
send(3, "\324g\1\0\0\1\0\0\0\0\0\0\tlocalhost\7example\3"..., 43,
MSG_NOSIGNAL) = 43
res search result: 57

We see that we get a different result - the one your Postfix code change
was trying to avoid.


To compile the source below, use either of these:

gcc -O -o try-resolv try-resolv.c -lresolv   # on Linux and Solaris
gcc -O -o try-resolv try-resolv.c# on FreeBSD/DragonflyBSD

/* try-resolv.c - a program to demonstrate a GNU libc resolver bug
   triggered by stripping RES_DEFSEARCH from _res.options. */
/* (C) 2011 Matthias Andree, MIT license,
   see http://opensource.org/licenses/mit-license */
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

unsigned char buf[512];

void barf(const char *s)
{
fputs(s, stderr);
exit(EXIT_FAILURE);
}

int main(int argc, char **argv) {
int res = res_init();
long opts;
long pfix_flags = RES_DEBUG | RES_DNSRCH | RES_DEFNAMES;

if (argc > 1 && 0 == strcmp(argv[1], "-h")) {
printf("Usage: %s [ []]\n", argv[0]);
exit(EXIT_SUCCESS);
}

if (res) barf("res_init() failed.");
printf("default _res.options = %lX\n", _res.options);
printf("strip flags= %lX\n", pfix_flags);
_res.options &= ~pfix_flags;/* strip flags */
printf("stripped _res.options = %lX\n", _res.options);
if (argc > 2 && sscanf(argv[2], "%li", &opts) == 1) {
_res.options = opts;
printf("forced _res.options = %lX\n", _res.options);
}

res = res_search(argc > 1 ? argv[1] : "localhost", C_IN, T_A, buf,
sizeof buf);
printf("res search result: %d", res);
if (res == -1) printf(", h_errno: %d (%s)", h_errno,
hstrerror(h_errno));
printf("\n");

exit(EXIT_SUCCESS);
}
/* end of try-resolv.c */

Hope that clears the recent issue.  I suspect that many older posts
(esp. before 2006) were related to domains where localhost.example.org
wasn't defined.

Best regards,
Matthias

Re: localhost pitfall in resolver/solving "Host or domain name not found. Name service error for name=localhost type=A: Host not found" (also type=AAAA)

[Matthias Andree]

Am 05.05.2011 04:11, schrieb Matthias Andree:

> Now, possible workarounds:
> 
> - be sure that /etc/resolv.conf contains a "search" list where at least
> one of the listed domains has a direct localhost resolving to 127.0.0.1
> and/or ::1.  Say, if you have "search example.com another.example", at
> least localhost.example.com or localhost.another.example must resolve IN
> DNS - /etc/hosts doesn't work here.
> 
> - add "options ndots:0" to /etc/resolv.conf (if setting multiple
> options, check your manual - my resolver needs them all on only one
> options line, separated by blanks). Be wary of system configuration
> tools that rewrite /etc/resolv.conf, they might lose this option.
> 
> - make sure to use a local "search" domain first in /etc/resolv.conf
> that has a localhost entry. For instance, if /etc/resolv.conf contains
> "search example.org", be sure there is a "localhost.example.org" DNS
> entry that resolves in class IN and type A to 127.0.0.1 and/or type 
> to ::1.

Gee. None of that works without affecting other parts of the system. The
first and last don't work on current Postfix versions, and the middle
option breaks qualifying the very own hostname.

I'll withdraw these workaround proposals.

Postfix-specific workaround (dangerous, as it can cause misresolving):

/etc/postfix/main.cf:
smtp_dns_resolver_options=res_defnames   # don't do this

See my other reply (to Wietse) in this thread for details.

Instead, ask your vendor to fix their resolver,
<http://sourceware.org/bugzilla/show_bug.cgi?id=12734>

localhost pitfall in resolver/solving "Host or domain name not found. Name service error for name=localhost type=A: Host not found" (also type=AAAA)

[Matthias Andree]

Greetings,

and sorry for the subject spam with search engine fodder, but I've
wasted hours debugging something that wasn't obvious but I believe I
have a somewhat useful overview now that I'd like to share.

My problem was that Postfix's smtp could not DNS-resolve "localhost",
but could resolve other domains. Symptom in the log:

  Host or domain name not found. Name service error for name=localhost
type=A: Host not found

  Host or domain name not found. Name service error for name=localhost
type=: Host not found

This "localhost" I was trying to resolve was procured from a transport
map as "[localhost]", in order to use an SSH tunnel for
semi-authenticated relaying.  "localhost" is also often used for
filtering when the filter software runs on the same computer as Postfix.

Now, observe there are common configurations that don't play together well:

- The typical DNS resolver looks for names without dots in a "search"
list. This is either configured explicitly (possibly automatically) in
/etc/resolv.conf, or taken from the "domain", or derived from the hostname.

- The typical DNS resolver does not try a direct look up of names
without dots at all.

- Not all DNS zones provide a "localhost" hostname record, or if they
do, only at the top level - where it's invisible if subdomains are used,
such as mycomputer.mydepartment.example.org.

The consequence is that in such circumstances, "localhost" is not
reliably resolvable.

This problem is exacerbated by the fact that Postfix does not allow me
to use "localhost." instead -- this would have been a fully-qualified
host name that defeats the domain search, and I've yet to see a resolver
that balks at "localhost." with trailing dot.

(Note that the DNS root zone is called "." and DNS is a hierarchical
system rooted at the last component - the top-level domain.)


Now, possible workarounds:

- be sure that /etc/resolv.conf contains a "search" list where at least
one of the listed domains has a direct localhost resolving to 127.0.0.1
and/or ::1.  Say, if you have "search example.com another.example", at
least localhost.example.com or localhost.another.example must resolve IN
DNS - /etc/hosts doesn't work here.

- add "options ndots:0" to /etc/resolv.conf (if setting multiple
options, check your manual - my resolver needs them all on only one
options line, separated by blanks). Be wary of system configuration
tools that rewrite /etc/resolv.conf, they might lose this option.

- make sure to use a local "search" domain first in /etc/resolv.conf
that has a localhost entry. For instance, if /etc/resolv.conf contains
"search example.org", be sure there is a "localhost.example.org" DNS
entry that resolves in class IN and type A to 127.0.0.1 and/or type 
to ::1.



I wonder if, in the long run:

- Postfix should treat "localhost" special and force a direct query
before allowing the search list; or

- Postfix should generally try a direct query before the search list;
(probably warrants a version bump to 3.0 rather than 2.9), or

- Postfix should permit hostnames with trailing dots to prevent domain
hunts, or

- IETF or UNIX standardization efforts should be made instead to get the
resolver defaults corrected.

Looking forward to comments.

Best regards,
Matthias

Re: lmtp/smtpd incompatible WRT XFORWARD in 2.7.0?

[Matthias Andree]

Bug report requesting backport:

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

(This is a regression in Ubuntu lucid (10.04 LTS) from 8.04 LTS.)

Re: lmtp/smtpd incompatible WRT XFORWARD in 2.7.0?

[Matthias Andree]

Am 04.05.2011 19:54, schrieb Victor Duchovni:
> On Wed, May 04, 2011 at 07:45:32PM +0200, Matthias Andree wrote:
> 
>> Greetings,
>>
>> I seem to have XFORWARD troubles with Postfix 2.7.0 lmtp <-> smtpd
>> interoperability.  Amavisd-new is in the game, too, but looks innocent.
>>
>> Looks like the XFORWARD code in Postfix's lmtp client generates
>> attributes ("PORT=unknown") that the smtpd doesn't permit.
> 
> 20100515
> 
> Bugfix (introduced Postfix 2.6): the Postfix SMTP client
> XFORWARD implementation did not skip "unknown" SMTP client
> attributes, causing a syntax error when sending a PORT
> attribute. Reported by Victor Duchovni. File: smtp/smtp_proto.c.
> 
> The latest 2.7.x release is 2.7.3, this fix is included in that
> release.
> 

I wonder how I missed that grepping HISTORY for XFORWARD.  Sorry for the
noise.

Now let's wager when, if ever, Ubuntu will fix that in 10.04 LTS. :)

lmtp/smtpd incompatible WRT XFORWARD in 2.7.0?

[Matthias Andree]

Greetings,

I seem to have XFORWARD troubles with Postfix 2.7.0 lmtp <-> smtpd
interoperability.  Amavisd-new is in the game, too, but looks innocent.

Looks like the XFORWARD code in Postfix's lmtp client generates
attributes ("PORT=unknown") that the smtpd doesn't permit.

Is this a Postfix bug in lmtp (or smtpd) as of 2.7.0?

Problem shown in the last three lines of the log below.

The mail rig is:

   10.0.0.2  <- IPs
   mx2  mail  mail   <- hostnames
-> Postfix 2.3.4 -> Postfix 2.7.0 <-> amavisd-new 2.6.4  <- software
   (listed MX)   |
 `--> local(8) maildrop_command=maildrop -a -d

mx2 is outside my control, everything else is under my control.

First the logs, we see here three sessions with partial overlap:

1. mx2 -> mail's smtpd, injecting the mail received from outside.

   Looks pretty innocent. We offer PORT= to the Postfix-2.3.4 at mx2,
   it doesn't use it. So that's not it.

2. lmtp with localhost port 10024, amavisd listening

   Looks fishy, as it sends PORT=unknown.

3. smtpd with localhost for amavisd's back-injection after filtering

   Looks picky, as smtpd complains about PORT=unknown from step #2.


Logs (edited) - look for PORT=unknown

postfix/smtpd[19432]: > mx2.example.org[10.0.0.2]: 220 mail.example.org
ESMTP Postfix (Ubuntu)
postfix/smtpd[19432]: < mx2.example.org[10.0.0.2]: EHLO mx2.example.org
postfix/smtpd[19432]: > mx2.example.org[10.0.0.2]: 250-mail.example.org
postfix/smtpd[19432]: > mx2.example.org[10.0.0.2]: 250-PIPELINING
postfix/smtpd[19432]: > mx2.example.org[10.0.0.2]: 250-SIZE 3200
postfix/smtpd[19432]: > mx2.example.org[10.0.0.2]: 250-VRFY
postfix/smtpd[19432]: > mx2.example.org[10.0.0.2]: 250-ETRN
postfix/smtpd[19432]: > mx2.example.org[10.0.0.2]: 250-XFORWARD NAME
ADDR PROTO HELO SOURCE PORT
postfix/smtpd[19432]: > mx2.example.org[10.0.0.2]: 250-ENHANCEDSTATUSCODES
postfix/smtpd[19432]: > mx2.example.org[10.0.0.2]: 250-8BITMIME
postfix/smtpd[19432]: > mx2.example.org[10.0.0.2]: 250 DSN
postfix/smtpd[19432]: < mx2.example.org[10.0.0.2]: XFORWARD NAME=unknown
ADDR=186.58.X.Y
postfix/smtpd[19432]: > mx2.example.org[10.0.0.2]: 250 2.0.0 Ok
postfix/smtpd[19432]: < mx2.example.org[10.0.0.2]: XFORWARD PROTO=ESMTP
HELO=186-58-X-Y.source.example SOURCE=REMOTE
postfix/smtpd[19432]: > mx2.example.org[10.0.0.2]: 250 2.0.0 Ok
postfix/smtpd[19432]: < mx2.example.org[10.0.0.2]: MAIL
FROM: SIZE=1731
postfix/smtpd[19432]: > mx2.example.org[10.0.0.2]: 250 2.1.0 Ok
postfix/smtpd[19432]: < mx2.example.org[10.0.0.2]: RCPT
TO: ORCPT=rfc822;lu...@my.example.org
postfix/smtpd[19432]: > mx2.example.org[10.0.0.2]: 250 2.1.5 Ok
postfix/smtpd[19432]: < mx2.example.org[10.0.0.2]: DATA
postfix/smtpd[19432]: > mx2.example.org[10.0.0.2]: 354 End data with
.
postfix/lmtp[19435]: < 127.0.0.1[127.0.0.1]:10024: 220 [127.0.0.1] ESMTP
amavisd-new service ready
postfix/lmtp[19435]: > 127.0.0.1[127.0.0.1]:10024: LHLO mail.example.org
postfix/smtpd[19432]: > mx2.example.org[10.0.0.2]: 250 2.0.0 Ok: queued
as A803E47DD5
postfix/lmtp[19435]: < 127.0.0.1[127.0.0.1]:10024: 250-[127.0.0.1]
postfix/smtpd[19432]: < mx2.example.org[10.0.0.2]: QUIT
postfix/lmtp[19435]: < 127.0.0.1[127.0.0.1]:10024: 250-VRFY
postfix/smtpd[19432]: > mx2.example.org[10.0.0.2]: 221 2.0.0 Bye
postfix/lmtp[19435]: < 127.0.0.1[127.0.0.1]:10024: 250-PIPELINING
postfix/lmtp[19435]: < 127.0.0.1[127.0.0.1]:10024: 250-SIZE
postfix/lmtp[19435]: < 127.0.0.1[127.0.0.1]:10024: 250-ENHANCEDSTATUSCODES
postfix/lmtp[19435]: < 127.0.0.1[127.0.0.1]:10024: 250-8BITMIME
postfix/lmtp[19435]: < 127.0.0.1[127.0.0.1]:10024: 250-DSN
postfix/lmtp[19435]: < 127.0.0.1[127.0.0.1]:10024: 250 XFORWARD NAME
ADDR PORT PROTO HELO SOURCE
postfix/lmtp[19435]: Using LMTP PIPELINING, TCP send buffer size is 4096
postfix/lmtp[19435]: > 127.0.0.1[127.0.0.1]:10024: XFORWARD NAME=unknown
ADDR=186.58.X.Y PORT=unknown
postfix/lmtp[19435]: > 127.0.0.1[127.0.0.1]:10024: XFORWARD PROTO=ESMTP
HELO=186-58-X-Y.source.example SOURCE=REMOTE
postfix/lmtp[19435]: > 127.0.0.1[127.0.0.1]:10024: MAIL
FROM: SIZE=1975
postfix/lmtp[19435]: > 127.0.0.1[127.0.0.1]:10024: RCPT
TO: ORCPT=rfc822;lu...@my.example.org
postfix/lmtp[19435]: > 127.0.0.1[127.0.0.1]:10024: DATA
postfix/lmtp[19435]: < 127.0.0.1[127.0.0.1]:10024: 250 2.5.0 Ok XFORWARD
postfix/smtpd[19432]: disconnect from mx2.example.org[10.0.0.2]
postfix/lmtp[19435]: < 127.0.0.1[127.0.0.1]:10024: 250 2.5.0 Ok XFORWARD
postfix/lmtp[19435]: < 127.0.0.1[127.0.0.1]:10024: 250 2.1.0 Sender
 OK
postfix/lmtp[19435]: < 127.0.0.1[127.0.0.1]:10024: 250 2.1.5 Recipient
 OK
postfix/lmtp[19435]: < 127.0.0.1[127.0.0.1]:10024: 354 End data with
.
postfix/lmtp[19435]: > 127.0.0.1[127.0.0.1]:10024: .
postfix/lmtp[19435]: > 127.0.0.1[127.0.0.1]:10024: QUIT
postfix/smtpd[19437]: > localhost[127.0.0.1]: 220 mail.example.org ESMTP
Postfix (Ubuntu)
postfix/smtpd[19437]: < localhost[127.0.0.1]: EHLO localhost
postfix/smtpd[19437]: > localhost

Re: qmgr warning

[Matthias Andree]

Am 08.04.2011 18:31, schrieb Wietse Venema:

Randy Ramsdell:

Ralf Hildebrandt wrote:

* Ralf Hildebrandt:

* Randy Ramsdell:

Apr  8 10:10:30 atlbl6 postfix/qmgr[11959]: warning: connect to transport 
private/retry: Connection refused

grep retry /etc/postfix/master.cf

what do you see?


# grep retry /etc/postfix/master.cf
retry unix  -   -   -   -   -   error
should be the result



Thanks. That was it. It appears the upgrade dealing with the config
files were not complete.


I recommend that you use  "postfix upgrade-configuration set-permissions"
just to be sure that there are no more surprises later.


This should've been in their RPM %post sections for a while, but isn't. 
I'd seen that a couple of days ago and filed a bug, no response yet:


<https://bugzilla.novell.com/show_bug.cgi?id=684302>

--
Matthias Andree

Re: problem using postfix and mailman

[Matthias Andree]

Am 07.04.2011 10:11, schrieb deconya:
> Hi list
> 
> I have diferent mailman lists mounted and I detected a problem making
> tests to access, If I use telnet using other mailserver (mailserver.es
> ) I receive this information:
> 
> telnet mail.mydomain.com  25
...

> rcpt to:  >
> 250 2.1.5 Ok
> data
> 354 End data with .
> subject: test
> test
> .
> 250 2.0.0 Ok: queued as 078C028A502
> quit
> 221 2.0.0 Bye
> Connection closed by foreign host.
> 
> but wronglist not exist. How it's possible this? Im using postfix making

> a relay, I post my postconf -n:

...

> relay_domains = lists.mydomain.com ,
> autoreply.mydomain.com 

#1 please don't post HTML or enriched format to mailing lists

#2 To solve the actual problem, you can add relay_recipient_maps with
proper content. See http://www.postfix.org/ADDRESS_CLASS_README.html

Re: problem using postfix and mailman

[Matthias Andree]

Am 07.04.2011 10:15, schrieb Daniel Bromberg:
> On 4/7/2011 4:11 AM, deconya wrote:
>> Hi list
>>
>> I have diferent mailman lists mounted and I detected a problem making
>> tests
>> to access, If I use telnet using other mailserver (mailserver.es) I
>> receive
>> this information:
>>
>> telnet mail.mydomain.com 25
>> Trying 84.88.68.66...
>> [SNIP]
>> 354 End data with.
>> subject: test
>> test
> Again the quoting problem of literal SMTP conversations embedded in a
> message that is actually its own SMTP transaction. Move the trailing '.'
> in by one space in order to not cut off your own message.

Daniel, (in courtesy cc:)

the problem appears to be at your end (particularly if you write
"again") - likely some sendmail-command-style reinjection without -i or
-oi -- check your filters and fetchers.

The message has arrived in complete form on my end, and also at GMANE,
where you can read the remainder of the post:
.

Best
Matthias

Re: bcc: header

[Matthias Andree]

Am 25.03.2011 00:15, schrieb Murray S. Kucherawy:


MTA history goes back to sendmail, which had three main modes for injecting a 
message:

1) sendmail user@host
[message header and body here]
["." or EOF]

2) sendmail -t
[message header and body here]
["." or EOF]


Both commands should add -oi so that lines with dots get byte-stuffed 
("escaped") properly.


--
Matthias Andree

Re: postfix performance

[Matthias Andree]

Am 23.03.2011 23:06, schrieb Jeroen van Aart:
> I am curious if postfix would be able to send out 30 emails in one
> hour, to different recipients of course. Taking into account
> http://www.postfix.org/TUNING_README.html and other such performance
> tuning guides. This would only happen once a week or so. The important
> part is the need to send them all in one hour, more or less.
> 
> This would be on a debian server with about 64 to 92 GB of memory, 8 or
> 16 CPUs and a really fast internet connection.
> Considering 30 per hour equates to about 83 emails per second and
> given a reasonably fast server (over specced since I doubt CPU and RAM
> would be the bottleneck here) I would think one server could handle this.

I/O will be the bottleneck unless you do hefty filtering.

Network as well as local disk I/O.

Consider server-class SLC SSD if needed (and beware that flash memory
wears out over write operations), and be sure to keep a watch on the
NIC's send queues - don't let them run too long even under load if you
want to keep DNS latency down (which you should).  Check man tc, or the
Linux Advanced Routing and Traffic Control HOWTO.

Re: bcc: header

[Matthias Andree]

Am 23.03.2011 21:35, schrieb Jeroen van Aart:
> Matthias Andree wrote:
>> Yes - you seem to be misunderstanding how SMTP works. See RFC5321 [1]
>> for an explanation; for delivery, it matters ONLY what's in the
> 
> I don't misunderstand in as much that I just barely ever had the need to
> use bcc.
> 
>> RCPT TO:
>>
>> commands, not what's in the DATA section.
> 
> Yes I am aware of RFC5321. I assumed that since you add "cc:" and
> "subject:" in the DATA section the same goes for a "bcc:" list.

You may be aware of it, but I don't believe you've got the full picture yet.

The contents are not relevant for routing and delivery.  Cc:/Bcc:
headers are only looked at on initial injection through sendmail -i -t
or thereabouts.

The post service doesn't care what Cc: you write on your letters either,
but only looks at the envelope.

If I write "Amsterdam" on the envelope (RFC5321) and "Paris" on the
letterhead inside (the DATA part, as specified by RFC5322), where does
the letter go to?

> Would I need to issue separate "rcpt to:" commands in the same session
> to accomplish a bcc? If I try that then postfix does not remove the
> bcc'ed addresses.

Yes to the RCPT TO (and do mind the syntax, you'd got it wrong) -- and
Postfix is not supposed to tamper witht the Bcc:, in fact, cleanup(8) is
not consistently documented to eliminate Bcc: headers.

> However, if I issue multiple "rcpt to:" commands AND then add an empty
> "bcc:" header field after DATA.
> 
> Am I correct into thinking this then is the correct procedure of sending
> bcc emails using postfix?

There are several ways - the safest and easiest is not to include the
Bcc header at all (it is a crutch for setups that do not specify an
envelope, as, for instance, sendmail -t -i or sendmail -t -oi), and just
specifying the recipients-to-be-bcc'd in RCPT TO:<> commands.
You don't need such a crutch if you're talking SMTP.

Re: bcc: header

[Matthias Andree]

Am 23.03.2011 21:38, schrieb Jeroen van Aart:

> How come that postfix treats multiple "rcpt to:" commands differently
> depending on the presence of a "bcc:" header in the data section? 

I don't believe that it does that.  It's likely some component further
down the delivery path - check the logs.

Re: bcc: header

[Matthias Andree]

Am 23.03.2011 20:55, schrieb Jeroen van Aart:
> I tried the following in telnet session, but for some reason the email
> is only sent to the rcpt to: address. None of the Bcc'ed addresses
> receive a copy. Am I missing something obvious?

Yes - you seem to be misunderstanding how SMTP works. See RFC5321 [1]
for an explanation; for delivery, it matters ONLY what's in the

RCPT TO:

commands, not what's in the DATA section.

[1] http://tools.ietf.org/html/rfc5321

Re: Replace Message-Id with header_checks

[Matthias Andree]

Am 23.03.2011 14:19, schrieb Andrea Di Mario:
> Hi, I've a relay server that receives emails from some other. For some
> of these servers, that have a particular prefix, i wrote some
> header_checks' rules to change header, now i want rewrite the
> Message-Id header and i wrote:
> 
>  if /^Message-Id: <(.*)@prefix.*\.domain\.tld>$/ REPLACE Message-Id:
> <$1...@domain.tld>
> endif
> 
> It doesn't work. Could you tell me some suggestions?

Don't mess with Message-IDs.  They are supposed to be unique, and if
that's not the case, messages may get discarded as duplicates, and
nobody ever knows.

Re: [SPAM] - Re: Address Tagging in Postfix? - Bayesian Filter detected spam

[Matthias Andree]

Am 22.03.2011 22:53, schrieb Simon Brereton:

> The number of javascript email input validations that wouldn't allow + as a 
> valid character (particularly the banks) forced me to change 
> [recipient_delimiter] to - without any dire consequences...

Possibly not but some environments are fond of double family names,
making for interesting ambiguities around the minus character.  Check
the *complete* user list before using a recipient_delimiter of -.

Re: Postfix und SSL client problem.

[Matthias Andree]

Am 09.03.2011 10:14, schrieb kapetr:
> Hello,
> 
> 
> "Victor Duchovni"  wrote:
>>> 1.   How to get SSL certificate of smtp.iol.cz
>>> (and save it to
>>>> file).
>>
>> Use "openssl s_client -showcerts"
> 
> Thanks - it works. Interesting is, that I get this way only 2
> certificates:
> 
> CN=smtp.iol.cz   (issuer CN=Thawte SSL CA) and
> CN=Thawte SSL CA  (issuer CN=thawte Primary Root CA)
> 
> it is missing the Thawte root certicate CN=thawte Primary Root CA.
> Fortunately I have found this certificate is in /etc/ssl/certs.

Since the client needs the root certificate in its trusted store anyways
(usually /etc/ssl/certs or /usr/ssl/certs, or /etc/ssl/cert.pem as a
bundle, for system-wide OpenSSL installs anyways), there is no point in
the server sending it.  And if you retrieved it through the same channel
that you're fetching the mail through later, you couldn't trust it
anyways but would have to configure it separately.

> So .. I had to copy these tree certificates in
> /var/lib/stunnel4/certs (chroot of stunnel4),
> make the "hash" links (with help of openssl x509  -subject_hash
> -noout -in xyz), modify my stunnel.conf:
> 
> [ssmtp_client_iol]
> client = yes
> accept = 10465
> connect = smtp.iol.cz:465
> verify = 3
> CApath = /certs

Whatever stunnel's purpose is in your setup (I'm jumping late into the
thread), stunnel is generally insecure unless you can make bullet-proof
guarantees that nothing else can ever grab port 10465 than this
particular stunnel instance.  You often can't guarantee that, and
someone else can hook a password sniffing application to port 10465
transparently.  Setting up a system in a way that it can safely run
stunnel is very hard, because the system must prevent stunnel users from
running/starting if stunnel isn't up.

-- 
Matthias Andree

Re: mysql GPL/postfix IPL incompatibility

[Matthias Andree]

Am 28.02.2011 23:57, schrieb Quanah Gibson-Mount:

> The main issue I see at the moment really is the inability to legally
> link Postfix to MySQL, removing a valuable piece of Postfix functionality.

Not a loss.  If MySQL and Postfix turn out to be incompatible
license-wise, this prevents one particular SQL *implementation* from
being used - but not the functionality (SQL lookups) per se.

If you cannot or do not want to use MySQL due to licensing, use
PostgreSQL.  It not only removes the license worries [1], but also
worries around table storage engines, transactional modes, and ACID
compliance.

[1] 

Re: [PATCH] postfix won't build on FREEBSD 7.2+

[Matthias Andree]

Am 27.02.2011 20:41, schrieb Sahil Tandon:
> On Sun, 2011-02-27 at 18:33:39 +0100, Matthias Andree wrote:
> 
>> Am 26.02.2011 00:52, schrieb Sahil Tandon:
>>> On Fri, 2011-02-25 at 10:50:45 +0100, kristof.vans...@telenet.be wrote:
>>>
>>>> This problem exist in the 2.7 and 2.8 branch: 
>>>>
>>>> In file included from attr_clnt.c:77: 
>>>> /usr/include/unistd.h:329: error: conflicting types for 'closefrom' 
>>>> ./sys_defs.h:1399: error: previous declaration of 'closefrom' was here 
>>>> *** Error code 1 
>>>>
>>>> Stop in /home/src/postfix-2.7.2/src/util. 
>>>> *** Error code 1 
>>>>
>>>> Stop in /home/src/postfix-2.7.2. 
>>>
>>> Ah, you are not using the ports infrastructure, in which sys_defs.h has
>>> been patched to be aware of the closefrom() system call in 702104 and
>>> other FreeBSD versions.
>>>
>>> FWIW, this issue was discussed[1] on -devel a few months ago.
>>
>> Maybe, but pulling the patch into the upstream sources would seem right
>> to put this refinement where it belongs, no?
> 
> I do not understand your response.  "Maybe" what?  The patch for
> upstream has already been proposed in the link I pasted earlier in this
> thread.  So, naturally, I agree that upstream is the correct place for
> this "refinement".  When some iteration of it is incorporated by Wietse,
> we'll just remove it from ports.
> 

Yeah.  The simplest thing would be ditching FreeBSD 7.1 support (FreeBSD
7.1 will be discontinued after tomorrow).

Surely an upstream modification shouldn't introduce regressions either,
so let's not make too much noise about that but hope that Kristof or you
can come up with a refined patch :)

Re: [PATCH] postfix won't build on FREEBSD 7.2+

[Matthias Andree]

Am 26.02.2011 00:52, schrieb Sahil Tandon:
> On Fri, 2011-02-25 at 10:50:45 +0100, kristof.vans...@telenet.be wrote:
> 
>> This problem exist in the 2.7 and 2.8 branch: 
>>
>> In file included from attr_clnt.c:77: 
>> /usr/include/unistd.h:329: error: conflicting types for 'closefrom' 
>> ./sys_defs.h:1399: error: previous declaration of 'closefrom' was here 
>> *** Error code 1 
>>
>> Stop in /home/src/postfix-2.7.2/src/util. 
>> *** Error code 1 
>>
>> Stop in /home/src/postfix-2.7.2. 
> 
> Ah, you are not using the ports infrastructure, in which sys_defs.h has
> been patched to be aware of the closefrom() system call in 702104 and
> other FreeBSD versions.
> 
> FWIW, this issue was discussed[1] on -devel a few months ago.

Maybe, but pulling the patch into the upstream sources would seem right
to put this refinement where it belongs, no?

Re: [PATCH] postfix won't build on FREEBSD 7.2+

[Matthias Andree]

Am 25.02.2011 10:50, schrieb kristof.vans...@telenet.be:
> This problem exist in the 2.7 and 2.8 branch:
> 
> 
> In file included from attr_clnt.c:77:
> /usr/include/unistd.h:329: error: conflicting types for 'closefrom'
> ./sys_defs.h:1399: error: previous declaration of 'closefrom' was here
> *** Error code 1
> 
> Stop in /home/src/postfix-2.7.2/src/util.
> *** Error code 1
> 
> Stop in /home/src/postfix-2.7.2.
> 
> Fix:
> 
>  
> 
> src/util/sys_defs.h
> 
> 114c114
> < #if (__FreeBSD_version >= 702104 && __FreeBSD_version < 80) ||
> (__Fversion >= 800099)  /* safe; don't believe the experts */
> ---
>> #if __FreeBSD_version >= 800107   /* safe; don't believe
> thts */
> 

Hi Kristof,

dank je wel et merci. The fix per se looks sane to me, but the patch
doesn't apply to 2.8.1. "patch:  Only garbage was found in the patch
input."

Could you please re-diff:

- in the proper direction (you had swapped unpatched and patched)

- in unified or context format (-c or -u option)

- without truncating lines.

As to the latter, *attach* the patch, so as to keep whitespace intact.

Copy & paste doesn't work well for patches, so (you may need other diff
options such as -r depending on whether you diff from the top-level
directory of a copy of the tree)

diff -c UNPATCHED PATCHED >somefile
# then, send mail and attach "somefile"

(I think I recall Wietse prefers context format.)

Best regards
Matthias

Re: warning: truncate before-queue filter speed-adjust log: Permission denied

[Matthias Andree]

On Fri, 18 Feb 2011, Wietse Venema wrote:

> Please file a ZFS bug reportug. As per POSIX, when the O_CREAT is
> specified to open(),
> 
> The third argument does not affect whether the file is open
> for reading, writing or for both.
> 
> In other words, read/write access is controlled with the O_RDWR flags,
> not the read/write permissions argument.
> 
> When the above error happens, Postfix discards the file. Consequently,
> Postfix performance will be reduced, because it creates one extra file
> per MAIL transaction, instead of one extra file over the process
> lifetime.

That being said, I found ZFS performance abysmal, that is with a
single-disk pool (one partition on an enterprise-class 7200/min HDD,
amd64, 4 GB DDR3 ECC RAM, Phenom II X4 905e i. e. 4 x 2.5 GHz) on
FreeBSD 8.X, and ZFS prefetching enabled in the loader tunable.

I'd been running /usr with compression enabled, and stat() effort,
writes, and thereabouts were unbearably slow, even with a 85% filled
partition (the pool was 100% full one time before).  I've switched to
UFS2 on a 5400/min eco-consumer-class drive for the nonce and it just
flies.  I haven't analyzed this, but it seems there still are a few
rough edges in ZFS-on-FreeBSD that need to be filed down a bit :)

Note that ZFS on FreeBSD also still has a bug that it can't delete files
if the partition is full. You need to manually truncate files (to create
room for the relevant deletion log entries) before you can remove files.
(I've file a problem report for that but don't know the PR # yet.)

Re: FreeBSD tuning for a dovecot + postfix server ?

[Matthias Andree]

Am 14.02.2011 11:08, schrieb Frank Bonnet:

Hello

I've googled around to tune a bit my mailhub ( AMD64 FreeBSD 8.1, 12 Gb
RAM, 2 Tb raid5 disks , ~4000 mailboxes unix users )
but I am a bit confused,

All my clients use thunderbird as MUA ( IMAP, IMAPS ) to connect to the
mailhub
no direct access to the machine.

Any of you guys has some pointer to give ?


What's the question again?  What's the problem you're trying to solve?

--
Matthias Andree

Re: message tracking logging request

[Matthias Andree]

Am 02.02.2011 04:43, schrieb Alan Batie:
> While it's a much more minor matter, the ID suggestion *is* still
> pertinent - that's *not* something a simple configuration hack will fix,
> and it would be nice to have
Alan,

Postfix logs the ID whenever one is available, and it did in your case.
I'm wondering what exactly you seem to be missing. If it's about the
client connection as logged by postfix/smtpd, then it has no connection
to individual messages, hence doesn't have IDs associated. If messages
get rejected before entering the system (which a proper configuration
could and should attain BTW), there is no ID either because there is no
queue file.

HTH

-- 
Matthias Andree

Re: problem with added spaces in the message body

[Matthias Andree]

Am 21.01.2011 02:18, schrieb Vince Wang:
> Hi,
> 
> We are using postfix to send html version newsletter, and we found that the
> postfix(?) adds spaces into the body.
> 
>  
> 
> The message body is saved in database so we can preview it to make sure it is 
> right.
> 
>  
> 
> If the space is added between works or tags, it is fine, somehow  space is 
> added
> within word and make work such as officials to offi cials, and sometimes space
> is added in the url.
> 
>  
> 
> I would like to know if it  is possible to configure postfix to fix it, or any
> other ways.

Sounds like a strong allegation.  Can you confirm that

- the message itself is formatted properly (line length limits according to
relevant IETF standards/RFCs and all that) and not mangled by the database 
export?

- that it's actually Postfix that adds the blanks in the midsts of tokens

- that you're not abusing Postfix to send unsolicited mail?

-- 
Matthias Andree

Re: Load issues with Postfix on FreeBSD

[Matthias Andree]

Am 15.12.2010 19:37, schrieb Dave Brodin:
> Thanks to everyone for suggestions about the load issue.  I will 
> endeavor to provide more specific information.  It took a while to move 
> everything off of that server so I could do the load testing with 
> smtp-source.  Let me preface by saying that my real systems 
> administrator took another job, so I am filling in.  Unfortunately, I am 
> not proficient with commands to analyze disk and memory performance.  I 
> ran iostat, but I'm not sure how to interpret the results.

Thanks for pasting the material.

Post a snippet (perhaps ~20 lines if figures are somewhat consistent within a
scenario) of either scenario, and be sure to paste the column headers that
iostat output starts with.


> last pid:  3429;  load averages:  1.85,  0.44,  0.16up 6+04:33:18  
> 13:17:44
> 84 processes:  13 running, 71 sleeping
> CPU:  1.9% user,  0.0% nice, 98.1% system,  0.0% interrupt,  0.0% idle

This means most time is spent in the kernel.  Are you using ZFS?  I've seen
reports fly by that ZFS was bogging computers down.

> Mem: 171M Active, 6548M Inact, 842M Wired, 246M Cache, 827M Buf, 104M Free
> Swap: 4096M Total, 60K Used, 4096M Free
> 
>PID USERNAME   THR PRI NICE   SIZERES STATE   C   TIME   WCPU 
> COMMAND
>   3350 postfix  1 1000 37580K  5572K RUN 4   0:08 25.32% 
> smtpd
>   3353 postfix  1 1000 37580K  5572K RUN 7   0:08 25.31% 
> smtpd
>   3351 postfix  1  200 37580K  5572K lockf   3   0:07 23.97% 
> smtpd
>   3354 postfix  1  990 37580K  5572K CPU17   0:07 23.97% 


> 
> [root] iostat 10
> tty   mfid0mfid1 cpu
>   tin  tout  KB/t tps  MB/s   KB/t tps  MB/s  us ni sy in id
> 0   119 28.15   7  0.20  95.44   6  0.58  57  0  0  0 43
> 018  6.67   0  0.00   0.00   0  0.00   0  0  0  0 100
> 0 6  0.00   0  0.00   0.00   0  0.00   0  0  0  0 100
> 039 12.98  32  0.40  12.89   1  0.01   2  0 81  0 16
> 038 12.55  31  0.38   0.00   0  0.00   2  0 98  0  0
> 041 12.93  31  0.39  40.91   1  0.04   2  0 98  0  0
> 040 13.27  35  0.45  32.00   0  0.02   2  0 98  0  0
> 042 12.79  31  0.39  16.00  12  0.19   2  0 98  0  0
> 046 12.55  29  0.36  40.17   1  0.05   2  0 90  0  8
> 0 6 16.86   7  0.12  43.78   2  0.08   3  0 22  0 75
> 0 6 19.33   1  0.01   0.00   0  0.00   3  0 22  0 75
> 0 6  0.00   0  0.00  85.40   3  0.25   3  0 22  0 75
> 0 6 15.85   8  0.12  19.82  13  0.25   3  0 23  0 74
> 0   276  6.67   0  0.00   0.00   0  0.00   2  0 12  0 86
> 0 6  0.00   0  0.00  16.00   0  0.00   0  0  0  0 100
> 
> Not sure if that is going to be helpful.  I'm trying to read through 
> some unix books to get more up to speed on troubleshooting i/o issues.

tps means transactions per second (how many operations, more or less), KB/t
shows how bit these transactions are on average.

We can state that there is little I/O going on, MB/s is consistently < 1, and
the tps count is low.

> We recently went to using mbx format files in user home directories.  So 
> the mail is delivered first to dmail, which then puts it in the files.  
> I wasn't involved in this decision, but it seems to be working find on 
> our current server.  I'll have to research maildirs to see if that makes 
> more sense.

I think we should first figure out why your software is spending so much time in
kernel space.

-- 
Matthias Andree

Re: Understanding TLS

[Matthias Andree]

Am 05.12.2010 11:41, schrieb Christian Roessner:
> Hi,
> 
> first of all, I am not an SSL expert, so I hope you could help me 
> understanding something. I have Postfix configured as MSA/MTA with latest 
> postfix experimental. On port 25 of the mx0.roessner-net, which is the main 
> mail exchanger for other MTAs, I do not offer AUTH, but want to offer 
> STARTTLS.
> 
> On the MSA side, the side to my clients, I wish to offer STARTTLS and AUTH. 
> So I put the smtpd_sasl_auth_enable=yes option into master.cf.
> 
> So far so good.
> 
> When I use telnet to connect to mx0.roessner-net.de 25, waiting for 
> postscreen to allow me sending EHLO, I only get the following list of 
> commands:
> 
> Trying 78.46.253.227...
> Connected to mx0.roessner-net.de.
> Escape character is '^]'.
> 220-mx0.roessner-net.de ESMTP
> 220 mx0.roessner-net.de ESMTP
> EHLO client.unitymedia.org
> 250-mx0.roessner-net.de
> 250-SIZE 31457280
> 250-ETRN
> 250-ENHANCEDSTATUSCODES
> 250-8BITMIME
> 250 DSN
> 
> Where is the STARTTLS? When I look at the logs, I see that servers use TLS to 
> communicate with my server. So could someone tell me, how the trick works? To 
> do TLS without seeing the STARTTLS command? And I do not have 465 open. Only 
> 25.
> 
> Thanks to anybody who might like to bring light into dark for me :-)

Check TLS_README (or .html or whatever you have aounrd) for the server-side TLS
settings, you need to add some smtpd_tls_* and tls_* options.

-- 
Matthias Andree

Re: no plain text subject

[Matthias Andree]

Am 18.11.2010 01:28, schrieb Stan Hoeppner:
> Subject:
> =?iso-8859-1?Q?Le_invitamos_a_asistir_a_la_Presentaci=F3n_de_la_Oportunid?=
>   
> =?iso-8859-1?Q?ad_de_negocio_en_ACN_Marketing_y_Servicios_de_Telecomunica?=
>   =?iso-8859-1?Q?ciones?=
> 
> Does anyone have a header_checks pcre that would allow me to reject or
> discard any email with an encoded subject such as, but not limited to,
> that above.  I.e. non plain text?
> 
> I can't recall ever receiving legit email with an encoded subject, only
> spam.

Oh, then why does your mailer encode your mail body as ISO-8859-1?  I
might argue that only spam would contain that.  Your mail body does not
bear any non-ASCII characters.

What I mean is that it's not spam because it's encoded. I've seen KOI8-R
declared on legit pure-ASCII mail, and it wasn't spam.  Not to say I
have seen lots of broken mailers that get MIME encoding wrong.  It's
subtle enough that many software packages break in corner cases.

openSUSE chroot setup for TLS workaround

[Matthias Andree]

Greetings,

I haven't checked if it's a flaw in my configuration, but anyways, for the  
records:


openSUSE 11.3 does not seem to automatically set up the TLS certs for the  
chroot if you have smtp_tls_CApath set, but not smtpd_tls_CApath (note the  
d in smtp vs. smtpd).


I needed to do this to get my SMTP client work again:

sudo c_rehash /etc/ssl/certs/ # just to be on the safe side
sudo rsync -av /etc/ssl/certs/ /var/spool/postfix/etc/ssl/certs --del  
--copy-unsafe-links -H


Note that smtpd_tls_CApath would call rsync -avH, which would copy  
symlinks verbatim into the chroot, which get broken along the way because  
there is no /usr/share/ca-certificates inside the Postfix chroot (this is  
a fault in SuSEconfig.postfix).


Note that SUSE /etc/ssl/certs .pem files are actually symlinks to  
/usr/share/ca-certificates/mozilla/... managed by update-ca-certificates,  
hence the copy-unsafe-links.


I don't currently have time to do a formal bug report against  
SuSEconfig.postfix, and I'm unsure if they or I care enough. Perhaps  
Carsten Höger reads this?


Best

--
Matthias Andree

Re: Fetchmail/Postfix

[Matthias Andree]

(To be fair, J C Potter provided a pastebin snippet with postconf -n, and  
the smtpd reject log line, but I'm not forwarding those to the list so as  
not to breach privacy.)


--
Matthias Andree

Re: Fetchmail/Postfix

[Matthias Andree]

Am 14.06.2010, 10:07 Uhr, schrieb JC Putter:

(about: User unknown in local recipient maps)

as the log show that a person is trying to email a user that does not  
have a local account on the postfix server, (the users does have an  
account on the mx host)  id like postfix to try and deliver to mail to  
the mx host


Still haven't understood your setup and have neither time nor energy to  
ask again.


I'll bluntly point you to local(8) and the fallback_transport_maps,  
fallback_transport, and luser_relay parameters. Check the docs if these  
help.


Also note that list traffic should be answered on the list. If your mailer  
doesn't have a list reply button, get a better mailer or for the nonce use  
reply to all.  Redirecting to the list.


--
Matthias Andree

Re: Fetchmail/Postfix

[Matthias Andree]

Am 13.06.2010, 20:03 Uhr, schrieb JC Putter:


hi everyone,

i have a postfix (2.3.3) server running with fetchmail to retrieve mail  
from
the actual mailserver, the problem is that only the office users get  
their
my from the local postfix/fetchmail server, the remote users connect to  
the

actual internet mailserver, the office users can send mail to the remote
users (user does not exist...) (i understand why).


This is unclear. fetchmail/postfix have no notion of office users or  
remote users or actual internet mailserver or thereabouts.


Show your configurations without passwords, and logs. See  
http://www.fetchmail.info/fetchmail-FAQ.html#G3 for the fetchmail side.



is it possible to configure postfix to relay mail to the domain mx  if it
cant find the users on the system?


Yes.

--
Matthias Andree

[PATCH] Re: OpenSSL 0.9.8 <-> 1.0.0 CApath (in)compatibility

[Matthias Andree]

[third resend to fill in Victor's reference - removed him from Cc: to  
avoid the dupe;

all in the hopes it finally makes it or I get at least an NDN]

Am 17.05.2010, 19:19 Uhr, schrieb Victor Duchovni:


On Mon, May 17, 2010 at 10:23:16AM +0300, Eray Aslan wrote:


On 17.05.2010 03:02, Victor Duchovni wrote:
> If you want to be really clever, you may be able to hash two copies
> of the root CA directories with the same set of certificates each with
> a different version of c_rehash (and corresponding utilities from the
> appropriate OpenSSL version) and then combine the set of symbolic  
links

> into a final directory that should work with either library. If you
> decide to take this approach, test carefully! No warranty!

There is a patch for openssl for the above c_rehash problem (not  
tested):


http://rt.openssl.org/Ticket/Display.html?id=2234

guest/guest for username and password works for loging in to rt.


The patch addresses a different issue: incorrect "PATH" handling
in c_rehash(1). I don't run into this, because when I want to use a
particular OpenSSL version, I put the right directory first in the PATH,
I don't rely solely on correct internal handling of the PATH by the
command-line tools.

The issue I am reporting is that neither the 0.9.8 nor the 1.0.0 c_rehash
generates a set of symlinks that the other can use. It is possible,
with care, to merge the symlinks built by each release (in separate
copies of the CApath directory) into a single set of symlinks (with
suitable adjustment of sequence numbers on hash "collisions"). I have
a Perl script that does this, but I am not prepared to support it.

If someone else wants to document and support such a tool, I can make it
available to the volunteer. It is ~100 lines of Perl that merges symlinks
from a set of working directories to a target CApath directory, which
is modified only to the extent necessary, existing correct symlinks are
always left in-place. This can be used on live CApath directories with
no little of transient verification errors.

The only race condition is when a trusted root is deleted which has the
same hash as a trusted root that stays, and the "hash.0" link needs to go
while the "hash.1" link stays. The script does this via rename("hash.1",
"hash.0"), but this cannot be made race-free, the verifier may have just
read the old "hash.0" link, and may be about to use the "hash.1" link.
Both hash collisions and deletion of trusted roots are rare. The race
window is very narrow. This is substantially safer than the crude
"delete all links, then make new links" approach of c_rehash.


Even if, let's extend the c_rehash tool because that's much less of a
hassle and can later be included upstream if desired.

*IMPORTANT:* Please CC: me on your feedback! I read the list only
sporadically for lack of time.

I offer an *UNSUPPORTED, NO WARRANTIES* patch (aka. use at your own risk)
against OpenSSL's OpenSSL_1_0_0-stable branch at
<http://homepages.uni-paderborn.de/mandree/openssl-c_rehash-both.patch>. I
reserve the right to remove it any time, without prior notice.

I'm not attaching it because I know the list driver is picky, but I don't
know how picky. I include an inline version for your perusal, but it will
likely not apply due to spacing differences, word wrapping and
thereabouts. If it fails, download it.

The patch adds -old_compat and -help options to c_rehash.

-help does the obvious (if given as first argument).

-old_compat (if given as first argument) will make c_rehash add
-subject_hash (as usual) and *also* -subject_hash_old hashes. Be sure to
keep OpenSSL 1.0.0's openssl application first in the path or point the
environment variable OPENSSL to it. CRL hashing hasn't been tested, let me
know how it goes.  If it works, I'll submit it for OpenSSL 1.0.0a.

--
Matthias Andree

openssl-c_rehash-both.patch
Description: Binary data

Patch *for perusal* (if it fails to apply, download from URL above!):

Re: postfix unavailable at 5 minutes after the hour?

[Matthias Andree]

Wietse Venema wrote on 2010-05-12:

> Uwe Dippel:
>> On 05/12/2010 07:13 PM, Wietse Venema wrote:
>> >> "fetchmail: connection to localhost:smtp [::1/25] failed: Connection
>> >> refused." is what I get in the mail at *:05.
>> >>
>> > Fetchmail wants to connect over IP VERSION 6.
>> >
>> > Apparently, Postfix does not listen on IP VERSION 6.
>> >
>>
>> Apparently.
>> Maybe I should ask on a fetchmail list, why fetchmail always and only 5
>> minutes past the hour tries to connect over IPv6!?
>
> It is only speculation, but perhaps fetchmail uses IPv6 because
> you have a record with:
>
>   ::1 localhost ...
>
> in /etc/hosts. That would explain why fetchmail tries to use that
> information. Of course it is not very nice that fetchmail spams
> you with error messages for this.

To confirm your speculations, indeed fetchmail 6.3.X would default its
outbound mail to localhost port 25 via SMTP, and use getaddrinfo() to
resolve localhost. This is documented.

Also, the cron spam can be silenced with - oh wonders - fetchmail's
--silent option. This is also documented.

Fetchmail versions 6.3.10 and newer (Ubuntu ships a 6.3.9 release
candidate) also use AI_ADDRCONFIG where supported by the OS, but that
doesn't help in this case because there is an IPv6 address configured
(else the error message would be unupported address, no route to host,
or  similar).

> So the "solution" is to nuke this entry from /etc/hosts or to turn
> on IPv6 support in Postfix (inet_protocols = all).

Workaround if the original reporter cannot fix /etc/hosts would be to
add  --smtphost 127.0.0.1 to fetchmail's command line, or smtphost
127.0.0.1 in  a "defaults" section of the rcfile.


[
EXCURSION:

I'd also like to mention that Ubuntu 10.04 LTS ("lucid lynx") ships a
way  outdated fetchmail version, because Ubuntu couldn't be bothered to
package  an up-to-date that was available before their freeze date. They
were told  weeks sooner and ignored the request.  Their excuse was not
having time to  adjust their local patches.  How convincing.  If more of
this crap hits  the lists, we'll need to put GPL clause 2a to the test ;-)
]


-- 
Matthias Andree

[SOLVED] Re: Postfix 2.5.1 cleanup(8) Date: issue?

[Matthias Andree]

Wietse Venema wrote on 2010-03-29:

> Matthias Andree:
>> and timezone are wrong, timezone name is missing). Interestingly, the  
>> time
>> logged in Received: is correct. I would have hoped that the Date: header
>> produces the same timestamp as in the Received: header.
> ...
>> Return-Path: <>
>> X-Original-To: ma+direct
>> Delivered-To: ma+dir...@example.org
>> Received: from x (localhost [127.0.0.1])
>>by mail.example.org (Postfix) with ESMTP id A3F59481E3
>>for ; Mon, 29 Mar 2010 16:38:10 +0200 (CEST)
>> Subject: yet another Postfix test
>> Message-Id: <20100329143810.a3f5948...@mail.example.org>
>> Date: Mon, 29 Mar 2010 16:38:10 +0200 (CEST)
>> From: MAILER-DAEMON
>> To: undisclosed-recipients:;
>
> In the above message:
>
> Received header date = Mon, 29 Mar 2010 16:38:10 +0200 (CEST)
> Date header date = Mon, 29 Mar 2010 16:38:10 +0200 (CEST)
>
> These time stamps are identical, and all headers have the form that
> I would expect from Postfix.

Thank you.  It matches what I'd read in the source (the strftime format string).

> This has a NON-POSTFIX Message-ID: header, and a Date: header
> without time zone.

That's ok, and wasn't what I'd tested.

Now that's embarrassing, for me (not noticing the discrepancy between mailer's
display and Maildir contents), and for the Opera guys (for goofing up the time
zone).

Here's the story:  I was looking at what Opera 10.51's mail client was
presenting me in "all headers and body" view (whatever the exact name is,  I'm
using a localized version).

Original:

Return-Path: <>
X-Original-To: ma+direct
Delivered-To: ma+dir...@example.org
Received: from x (localhost [127.0.0.1])
 by mail.example.org (Postfix) with ESMTP id E753548DA6
 for ; Mon, 29 Mar 2010 19:19:04 +0200 (CEST)
Subject: yet another Postfix test
Message-Id: <20100329171904.e753548...@mail.example.org>
Date: Mon, 29 Mar 2010 19:19:04 +0200 (CEST)
From: MAILER-DAEMON
To: undisclosed-recipients:;


Opera representation (Note Return-path misspelling, b0rked Date timezone, and
omitted To - it's not in the headline either):

Return-path: <>
X-Original-To: ma+direct
Delivered-To: ma+dir...@example.org
Received: from x (localhost [127.0.0.1]) by mail.example.org
  (Postfix) with ESMTP id E753548DA6 for ; Mon, 29 Mar 2010  19:19:04
  +0200 (CEST)
Subject: yet another Postfix test
Message-ID: <20100329171904.e753548...@mail.example.org>
Date: Mon, 29 Mar 2010 20:19:04 +0300
From: MAILER-DAEMON


Looks like a one of the many Opera mail bugs. Filed as bug #291618 with Opera,
and that bug address in Bcc: so they know this is being discussed in public.
Sorry for the lack of displomacy, but you get to share the embarrassment 
anyways :)

Off-topic: Anyone know a Thunderbird add-in that auto-creates virtual folders
for mailing lists? It's the sole reason why I'm still using Opera M2.

-- 
Matthias Andree

Postfix 2.5.1 cleanup(8) Date: issue?

[Matthias Andree]

rd_hosts = 127.0.0.1 10.0.0.25 10.0.0.28
smtpd_banner = $myhostname ESMTP $mail_name (Ubuntu)
smtpd_client_restrictions = cidr:/etc/postfix/filtered-clients-cidr
smtpd_etrn_restrictions = reject
smtpd_helo_required = yes
smtpd_helo_restrictions = reject_invalid_hostname permit_mynetworks
reject_non_fqdn_hostname
smtpd_recipient_restrictions = pcre:/etc/postfix/regexp_access
reject_unlisted_recipient reject_multi_recipient_bounce permit_mynetworks
permit_sasl_authenticated reject_unauth_pipelining
reject_unauth_destination
smtpd_restriction_classes = localsite_sender_access
smtpd_sasl_path = private/auth
smtpd_sasl_type = dovecot
smtpd_sender_restrictions = reject_non_fqdn_sender
reject_unknown_sender_domain reject_unlisted_sender
hash:/etc/postfix/access permit_mynetworks check_sender_mx_access
cidr:/etc/postfix/mx_cidr_access localsite_sender_access permit
smtpd_tls_cert_file = /etc/ssl/certs/dovecot.pem
smtpd_tls_key_file = /etc/ssl/private/dovecot.pem
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtp_helo_name = mailserver.example.org
unverified_sender_reject_code = 550

--master.cf--
smtp  inet  n   -   -   -   -   smtpd
submission inet n   -   -   -   -   smtpd
 -o smtpd_tls_security_level=encrypt
 -o smtpd_sasl_auth_enable=yes
 -o smtpd_client_restrictions=permit_sasl_authenticated,reject
 -o milter_macro_daemon_name=ORIGINATING
smtps inet  n   -   -   -   -   smtpd
 -o smtpd_tls_wrappermode=yes
 -o smtpd_sasl_auth_enable=yes
 -o smtpd_client_restrictions=permit_sasl_authenticated,reject
 -o milter_macro_daemon_name=ORIGINATING
pickupfifo  n   -   -   60  1   pickup
cleanup   unix  n   -   -   -   0   cleanup
qmgr  fifo  n   -   n   300 1   qmgr
tlsmgrunix  -   -   -   1000?   1   tlsmgr
rewrite   unix  -   -   -   -   -   trivial-rewrite
bounceunix  -   -   -   -   0   bounce
defer unix  -   -   -   -   0   bounce
trace unix  -   -   -   -   0   bounce
verifyunix  -   -   -   -   1   verify
flush unix  n   -   -   1000?   0   flush
proxymap  unix  -   -   n   -   -   proxymap
proxywrite unix -   -   n   -   1   proxymap
smtp  unix  -   -   -   -   -   smtp
relay unix  -   -   -   -   -   smtp
   -o smtp_fallback_relay=
showq unix  n   -   -   -   -   showq
error unix  -   -   -   -   -   error
retry unix  -   -   -   -   -   error
discard   unix  -   -   -   -   -   discard
local unix  -   n   n   -   -   local
virtual   unix  -   n   n   -   -   virtual
lmtp  unix  -   -   -   -   -   lmtp
anvil unix  -   -   -   -   1   anvil
scacheunix  -   -   -   -   1   scache
mailman   unix  -   n   n   -   -   pipe
 flags=FR user=list argv=/usr/lib/mailman/bin/postfix-to-mailman.py
 ${nexthop} ${user}
amavisfeed unix-   -   n-  2 lmtp
   -o lmtp_data_done_timeout=1200
   -o lmtp_send_xforward_command=yes
   -o disable_dns_lookups=yes
   -o max_use=20
127.0.0.1:10025 inet n-   n   -   - smtpd
   -o content_filter=
   -o smtpd_delay_reject=no
   -o smtpd_client_restrictions=permit_mynetworks,reject
   -o smtpd_helo_restrictions=
   -o smtpd_sender_restrictions=
   -o smtpd_recipient_restrictions=permit_mynetworks,reject
   -o smtpd_data_restrictions=reject_unauth_pipelining
   -o smtpd_end_of_data_restrictions=
   -o smtpd_restriction_classes=
   -o mynetworks=127.0.0.0/8
   -o smtpd_error_sleep_time=0
   -o smtpd_soft_error_limit=1001
   -o smtpd_hard_error_limit=1000
   -o smtpd_client_connection_count_limit=0
   -o smtpd_client_connection_rate_limit=0
   -o
receive_override_options=no_header_body_checks,no_unknown_recipient_checks
   -o local_header_rewrite_clients=

-- end of postfinger output --



-- 
Matthias Andree

documentation for owner-* companion aliases (was: Re: Message with 300,000+ recips via alias_maps)

[Matthias Andree]

Am 12.06.2009, 18:42 Uhr, schrieb Wietse Venema :


One final input: be sure to give each alias an owner-alias so that
Postfix will store the result of alias expansion in new queue
files.

Otherwise, the result of expansion will not be stored. After failure
of delivery to one local recipient in the expansion, the whole
alias will be expanded again when delivery is retried, which is
something that the other recipients will not appreciate.


Trying to explain this to an admin at a site I used to work for - where
(aka. in which file and section of Postfix documentation) is this owner-*
companion alias feature documented?

I have a vague notion of how this works, but postconf(5) on Postfix 2.5.5
(openSUSE 11.1) isn't particularly elucidating, and neither are
cleanup(8), trivial-rewrite(8) manpages (or qmgr(8), but that's not
concerned with rewriting), nor are virtual(5), generic(5), or
canonical(5) - the best you find is that owner-* and *-request are
treated special and, in a different place (postconf 5) that these bypass
splitting if recipient_delimiter is "-".

Am I missing documentation or is documentation on this feature too
terse?

TIA

--
Matthias Andree