[pfx] Re: [OT] Null MX or not?
I concur. My domain is a personal one for the use of me and my family. As such, there should not be an issue with other users sending spam or the like which would trigger mail to postmaster or abuse so the mail to those addresses is miniscule. And internally, they’re just forwarding addresses to my own email address. Should there be mail to one of them (the annual volume can be easily counted on one hand), they just show up in my personal email. -- Larry Stone lston...@stonejongleux.com > On Aug 1, 2024, at 7:33 AM, Bill Cole via Postfix-users > wrote: > > On 2024-08-01 at 03:32:52 UTC-0400 (Thu, 01 Aug 2024 07:32:52 +) > Laura Smith via Postfix-users > is rumored to have said: > My doubt is that since the outgoing email server identifies itself as > host1.example.com in the EHLO, is there a requirement or even an > expectation that postmas...@example.com will be able to receive email. > I think the reality is that we are in 2024, and the chances of a human > reading postmaster@ are about the same as a human reading abuse@ i.e. > nil. > OMG, I am apparently non-human... > Mail systems and their rates of abuse and/or technical trouble vary greatly. > > > b...@scconsult.com or billc...@apache.org > (AKA @grumpybozo@toad.social and many *@billmail.scconsult.com addresses) > Not Currently Available For Hire > > ___ > Postfix-users mailing list -- postfix-users@postfix.org > To unsubscribe send an email to postfix-users-le...@postfix.org ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: some questions about controlling postfix and meaning of data
As you have apparently now learned, there is a big difference between the sendmail package and the postfix sendmail command (which exists for compatibility reasons and is part of Postfix so no need to try to install it independently). -- Larry Stone lston...@stonejongleux.com > On Jan 19, 2024, at 9:30 AM, Don Cohen via Postfix-users > wrote: > > > (Sorry if this doesn't show up in the right thread, but these > problems actually caused me to lose the mail sent to me last > night, so I'm responding to what I see in the mailing list > archive.) > > All of my problems seem to have come from this original sin: > yum install ... postfix sendmail ... > > After uninstalling sendmail (and finding that sendmail now > refers to the postfix version, which I find pretty much > miraculous), all of my problems seem to be fixed and I can > undo all of what I did to work around them. > > ___ > Postfix-users mailing list -- postfix-users@postfix.org > To unsubscribe send an email to postfix-users-le...@postfix.org ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: 25 years today
I too appreciate Postfix. For several years, I ran my own mail server for my domain on a Macintosh at home. Postfix made it easy. Eventually, Apple made it too difficult plus increased travel made the idea of it running unattended for weeks made me nervous (I was not worried about Postix, I was worried about my Internet connection as well as network hardware in the house). But I still use Postfix as an outgoing-only mail server for mail generated by various programs on my computers. I also appreciate this list. As opposed to many other support venues that help people fix their current problem with no understanding of the issue, this list has always been more about education so the user understood what their issue was and could then fix it themself (give someone a fish, you feed them for a day; teach someone to fish, you feed them for life). That coupled with Wietse’s participation and being open to ideas generated by how us real-world users actually use Postfix (as opposed to some computer companies (I’m talking about you, Apple) that think they know the one, true way to use their product and any other way is wrong) along with his thorough knowledge of Postfix results in a very quick implementation of new ideas (where else can you offer an idea and a good reason for it and have a patch implementing it in a few hours?). All in all, well done! -- Larry Stone lston...@stonejongleux.com > On Dec 14, 2023, at 5:20 AM, Wietse Venema via Postfix-users > wrote: > > 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. > > Wietse > ___ > Postfix-users mailing list -- postfix-users@postfix.org > To unsubscribe send an email to postfix-users-le...@postfix.org ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
Re: Why the name Postfix?
On Mar 27, 2022, at 5:00 PM, Wietse Venema wrote: > Changing the name of a program is a lot of work; it is worse than > changing the name of the main character in a story. 20 to 30 years ago, I did a lot of work with DEC’s VMS operating system. The original working name for the OS was Starlet. Many references to Starlet remained at that time both inside files and as file names. I just checked on a current version VMS system I can access - found 18 STARLET* filenames in the system library directory. -- Larry Stone lston...@stonejongleux.com
Re: strange issue with postfix
> > On Oct 1, 2020, at 2:18 PM, Ranjan Maitra wrote: > > Thanks, very much. So when I hit "Send" on sylpheed, it goes on a tailspin, > and says: Connecting to SMTP server: localhost > > Looking at the /var/log/maillog as you suggested, I get: > > Oct 1 14:08:00 localhost postfix/smtpd[4142479]: fatal: in parameter > smtpd_relay_restrictions or smtpd_recipient_restrictions, specify at least > one working instance of: reject_unauth_destination, defer_unauth_destination, > reject, defer, defer_if_permit or check_relay_domains As someone else already replied, the problem is with the smtp_relay_restrictions or smtp_recipient_restrictions. > And here is what happens when I send mail from the commandline: > > Oct 1 14:11:42 localhost postfix/pickup[3995696]: 44C4416239C: uid=1000 > from= But when you use the command line, the mail enters Postfix via the pickup service. That’s completely different from smtpd (that’s the SMTP daemon). Command line works because having the mail enter via pickup does not use the bad smtpd_…_restrictions parameters. -- Larry Stone lston...@stonejongleux.com
Re: Installing sendmail in non-default location
> On Jul 27, 2020, at 1:18 PM, Viktor Dukhovni > wrote: > > >> make -f Makefile.init makefiles CCARGS='-DUSE_TLS -I/usr/local/ssl/include \ >> [...] >> -DDEF_SENDMAIL_PATH=\"/usr/local/sbin\"\ > > This is not correct, it lists the containing directory, rather than the > full path to the executable. > >> [...] >> sendmail_path=/usr/local/sbin > > This is not correct, it lists the containing directory, rather than the > full path to the executable. > Duh! And it was staring me in the face in the on-line documentation. Anyway, thanks for the reply. All works as desired now. -- Larry Stone lston...@stonejongleux.com
Re: Installing sendmail in non-default location
> On Jul 27, 2020, at 11:05 AM, Larry Stone wrote:
>
> I’m trying to figure out how to tell make {install | upgrade} to install
> sendmail eleswhere? I tried sendmail_path=/usr/local/sbin as well as
> -DDEF_SENDMAIL_PATH and while that changes the default value of
> sendmail_path, it still installs in /usr/sbin.
Never mind (at least somewhat). I found after pouring through the install
script that at least for upgrades, it looks at main.cf so once I changed it in
main.cf, it installed sendmail to /usr/local/sbin as I wanted.
Which leads to a new question. In working on this, I modified my “make
makefiles” to add a sendmail_path argument (which worked to change the default
value) and later as I worked through this, a -DDEF_SENDMAIL_PATH to CCARGS. Do
I need both in the “make makefiles” command? My full command is below (based on
a template Viktor provided me years ago although I think he recommends
something slightly different now).
make -f Makefile.init makefiles CCARGS='-DUSE_TLS -I/usr/local/ssl/include \
-DUSE_SASL_AUTH \
-DUSE_CYRUS_SASL \
-I/usr/local/include/sasl \
-DDEF_SERVER_SASL_TYPE=\"dovecot\"\
-DDEF_COMMAND_DIR=\"/usr/local/sbin\"\
-DDEF_SENDMAIL_PATH=\"/usr/local/sbin\"\
-DDEF_CONFIG_DIR=\"/usr/local/etc/postfix\"\
-DDEF_DAEMON_DIR=\"/usr/local/libexec/postfix\"\
-DHAS_PCRE -I/usr/local/include' \
AUXLIBS='-L/usr/local/lib -lpcre -L/usr/local/ssl/lib -lssl -lcrypto \
-L/usr/local/lib -lsasl2' \
sendmail_path=/usr/local/sbin
Thanks.
—
Larry Stone
lston...@stonejongleux.com
Installing sendmail in non-default location
I’m trying to figure out how to tell make {install | upgrade} to install
sendmail eleswhere? I tried sendmail_path=/usr/local/sbin as well as
-DDEF_SENDMAIL_PATH and while that changes the default value of sendmail_path,
it still installs in /usr/sbin.
Background: last week, I finally upgraded one of my Macintoshes to Catalina
(MacOS 10.15.6). I build Postfix from source. In this version, Apple has
tightened down modifications to the system even more (it’s now on a read-only
partition that normally only MacOS upgrade packages can modify). For the last
few versions, if you turned off Apple’s System Integrity Protection (SIP), the
Postfix make install | upgrade could install its version of the sendmail
executable in /usr/sbin. With Catalina, now you also need to remount the root
file system as writable (mount -uw /). I figure at some point Apple will find a
way to stop that as well. And I don’t need the Postfix built sendmail in
/usr/bin as I have Apple’s built-in Postfix configured to write to the same
queue files so it works fine anyway.
--
Larry Stone
lston...@stonejongleux.com
Re: Postfix on OSX 10.15.5 being overwritten by OS updates
Where are you installing Postfix? While I have yet to upgrade to Catalina (10.15.x), I have done a test of 10.15.4 with no Postfix issues. My Postfix is in /usr/local (built from source - no Homebrew or similar). MacOS upgrades should not be touching /usr/local. I would only expect issues if you installed it in the non-local part of /usr but you should not be able to install Postfix there unless you turned off SIP (System Integrity Protection). The various problems you are having suggest something very non-standard about your configuration. -- Larry Stone lston...@stonejongleux.com > On Jun 27, 2020, at 5:02 AM, Robert Chalmers (Author) > wrote: > > I’m wondering if it’s possible to install Postfix onto the OSX, so that it > doesn’t get overwritten by new updates to the OS every time. I have changed > things a few times but really. There must be a solution. Does anyone have a > useful suggestion? > Thanks > > Robert
Re: The historical roots of our computer terms
> On Jun 6, 2020, at 12:47, Wietse Venema wrote: > > Changing 'blacklist' into 'blocklist' or 'blackhole' into 'sinkhole' > seems doable. There is no 'slave' in documentation, program names > or parameter names. Internal identifiers and comments can be updated > with no visible consequence. Other changes would be difficult. Code changes introduce risk (as I no doubt don’t need to tell Wietse). I’m reminded from my days many, many years ago using VAX/VMS systems. In looking at the files that made up that operating system, I noticed a file name that seemed out of place (STARLET, IIRC) and didn’t fit the rest of the apparent naming scheme. I would eventually find out it was the pre-release “working name” of what would become VMS but by the time DEC settled on the VMS name, the old name was too embedded in the code to risk trying to change all the code. I’ve been away from VMS for 25 years or so but it wouldn’t surprise me if that old name still lives on in the current version. — Larry Stone lston...@stonejongleux.com
Re: The historical roots of our computer terms
> On Jun 6, 2020, at 9:20 AM, Wietse Venema wrote: > > Ian Evans: >> Food for thought from the co-author of OAuth and oEmbed. How easy would it >> be for Postfix/Postscreen configs/docs to, say, refer to allow/deny lists? > > Easily, if they can be acessed via DNSBL/DNSWL qeueries. Any 'new' > lookup mechanism will have to be added through a postscreen policy > plugin, and that involves new Postfix code. > > For context: Postscreen decides if a remote SMTP client is allowed > to talk to a Postfix SMTP service. The decision is made on (protocol) > behavior and reputation, plus a static allow/deny list that is > typically populated with information from major provider SPF records. Unfortunately, I believe the poster’s question was a political correctness question, not a technical question. -- Larry Stone lston...@stonejongleux.com
Minor logrotate bug (was Re: logrotate script for Postfix)
I posted the note below Saturday but having seen no acknowledgement from Wietse, wanted to make sure it wasn’t overlooked although it’s very minor. To summarize what’s below, the default value of maillog_file_rotate_suffix is %Y%M%d-%H%M%S which puts minutes where you expect month. It should be %Y%m%d-%H%M%S. And as I said, it’s technically not a bug because it works as documented but as documented and as works is not what one would reasonably expect. I’m running Postfix 3.5.1. -- Larry Stone lston...@stonejongleux.com > On May 9, 2020, at 10:31 AM, Larry Stone wrote: > >> >> On May 9, 2020, at 9:45 AM, Wietse Venema wrote: >> >> >> If the log is written by Postfix you must use "postfix logrotate". >> This ensures that Postfix stops writing to a file before it is >> compressed. >> >> Wietse > > I hate to even suggest I found a bug with Postfix, but I think I found a very > minor bug. > > First, despite having gone to Postfix logging over a year ago (thanks to > MacOS’s weird logging system), this is the first I heard there was a Postfix > logrotate command. Testing it, I did not get the rotated file name I would > have expected. The bug is the default name for the rotated file which is from > the parameter maillog_file_rotate_suffix: > # postconf -d maillog_file_rotate_suffix > maillog_file_rotate_suffix = %Y%M%d-%H%M%S > > This is putting minutes where month should be. And it’s documented that way > at http://www.postfix.org/MAILLOG_README.html (so technically not a bug since > it works as documented but not as one would expect). > > Easy fix with an override in main.cf > > -- > Larry Stone > lston...@stonejongleux.com
Re: logrotate script for Postfix
> > On May 9, 2020, at 9:45 AM, Wietse Venema wrote: > > > If the log is written by Postfix you must use "postfix logrotate". > This ensures that Postfix stops writing to a file before it is > compressed. > > Wietse I hate to even suggest I found a bug with Postfix, but I think I found a very minor bug. First, despite having gone to Postfix logging over a year ago (thanks to MacOS’s weird logging system), this is the first I heard there was a Postfix logrotate command. Testing it, I did not get the rotated file name I would have expected. The bug is the default name for the rotated file which is from the parameter maillog_file_rotate_suffix: # postconf -d maillog_file_rotate_suffix maillog_file_rotate_suffix = %Y%M%d-%H%M%S This is putting minutes where month should be. And it’s documented that way at http://www.postfix.org/MAILLOG_README.html (so technically not a bug since it works as documented but not as one would expect). Easy fix with an override in main.cf -- Larry Stone lston...@stonejongleux.com
Re: Using Postfix to send home server alerts
In an earlier note, Bob Proulx said "The best solution for you is the one you understand the best. That is the one you can manage the easiest.” For me, for historical reasons, that has been Postfix. For several years, I ran a full-fledged Postfix server on a Macintosh running at home. Static IP on DSL. Worked great. About four years ago, the cost to keep the DSL at a decent speed was getting too high so I switched to cable with a dynamic IP and outsourced the mail and web hosting of my domain. But I had processes running on the computer at home that needed to send mail. Easiest thing was to just leave Postfix running and as the cable company does not allow outgoing to port 25, have Postfix relay to my new mail provider using relayhost to the submission port. Other than adding relayhost and a password file referenced by smtp_sasl_password_maps, the only other change I needed to make to Postfix was to add Cyrus SASL (I has been using dovecot for smtpd but only Cyrus is supported for smtp (client)). Even though my computer at home is now on dynamic IP, it has a host name in my domain. The IP address has only changed once in those four years and one of those processes lets me know if it changes so I can quickly update DNS. Most of the processes on my computer send via the Postfix sendmail command although there is one that sends via SMTP so having a local STMP daemon is important (it looks like MSMTP that Peter recommended only works as sendmail command replacement). I’ve only had one issue which is one of those processes at home tries to send me a text message via T-Mobile’s email to text gateway (send email to phonenum...@tmomail.net). At some point in the last year, they started detecting that the mail was being double-relayed (home to mail ISP and the mail ISP to them) and rejecting it. My workaround is to have that process send directly to my mail ISP via CURL but that’s error-prone as a network outage will cause it to fail rather than being held for retry (but since this process retrieves mail from the mail ISP via fetchmail, analyzes it for some keywords, and immediately send the mail via CURL, the outage would have to happen in that fraction of a second between fetch and send). But I just tried it right now via the Sendmail command and it worked so maybe T-Mobile realized that this was rejecting too much legitimate messages. -- Larry Stone lston...@stonejongleux.com
Re: Mail rejected with 5.7.1 HDR9020 Date header is in the distant future
> On Jan 6, 2020, at 2:18 PM, Wietse Venema wrote: > > Larry Stone: >> Yep. Sadly, the mail provider I use for personal email had a spam >> check to consider dates 2020 and later to be ?from the future? and >> rejected mail. It took a few hours for them to fix it on 1/1, >> meanwhile, considerable mail was lost. Check your various spam >> checking processes. >> >> As my mail provider has told me they updated it to 2030, I now >> have a reminder set on my computer for 1-Dec-2029 to remind them >> to update it (should I still be using them 10 years from now). > > This is a Y.01K (Y-dot-01K? Y1K/100?) problem! If only every 10 years. It bit them 1/1/16 as well (just a month after I switched to them once I reached the conclusion that having a reasonably priced high bandwidth connection meant moving to my cable provider’s “no servers” residential offering so farewell to running a full functional Postfix server at home - I still run Postfix but only for sending out mail originating from daemons and cron jobs I run to monitor our systems). Back then, they told me they took steps to make sure it didn’t happen again. Oops. The lesson for all of us is that spam checks that require periodic updating to prevent false positives need a good support network in place to make sure they’re not forgotten (either inadvertently or due to personnel changes). The mail provider I use is basically a small “mom and pop” (by their own description) operation. The pro is when there is a problem, I don’t have to waste time with first level support who usually don’t know as much as I do and are primarily there to deal with clueless users and that at a small operation, it’s much easier to get the problem to the person who can quickly fix it. The con is that there usually isn’t 24x7 support (I got lucky that my support request via a web form did get to someone right away but as befits the “mom and pop” description, the person who called me back was clearly also a mom who at the same time was trying to feed the kids - you just don’t get that entertainment on a support call to a mega-corp). Anyway, that’s probably enough digression from true Postfix issues (although FWIW, I can tell that my mail provider also uses Postfix). -- Larry Stone lston...@stonejongleux.com
Re: Mail rejected with 5.7.1 HDR9020 Date header is in the distant future
On Jan 6, 2020, at 11:52 AM, Noel Jones mailto:njo...@megan.vbhcs.org>> wrote: > > On 1/6/2020 11:31 AM, Roel Wagenaar wrote: >> L.S. >> Lately I find rejections in my mail log, my mailers all have ntp running, >> yet the reject reason is: 5.7.1 HDR9020 Date header is in the distant >> future. >> Jan 6 18:18:24 mail1 postfix-in/smtpd[19887]: connect from >> english-breakfast.cloud9.net[168.100.1.7] >> Jan 6 18:18:24 mail1 postfix-in/smtpd[19887]: E59C49805: >> client=english-breakfast.cloud9.net[168.100.1.7] >> Jan 6 18:18:25 mail1 postfix-in/cleanup[19907]: E59C49805: reject: header >> Date: Mon, 6 Jan 2020 17:16:46 + from >> english-breakfast.cloud9.net[168.100.1.7]; >> from= to= proto=ESMTP >> helo=: 5.7.1 HDR9020 Date header is in the >> distant future >> Jan 6 18:18:25 mail1 postfix-in/smtpd[19887]: disconnect from >> english-breakfast.cloud9.net[168.100.1.7] ehlo=1 mail=1 rcpt=1 data=0/1 >> quit=1 commands=4/5 >> Anyone have an idea where I am to look for the problem? > > Your header_checks apparently has a rule to reject mail from 2020, or maybe > it doesn't like timezone +. Search your header_checks for your rule > HDR9020, and remove that rule. Yep. Sadly, the mail provider I use for personal email had a spam check to consider dates 2020 and later to be “from the future” and rejected mail. It took a few hours for them to fix it on 1/1, meanwhile, considerable mail was lost. Check your various spam checking processes. As my mail provider has told me they updated it to 2030, I now have a reminder set on my computer for 1-Dec-2029 to remind them to update it (should I still be using them 10 years from now). -- Larry Stone lston...@stonejongleux.com <mailto:lston...@stonejongleux.com>
Re: Question getting Mail.app working with PostFix SMTP
Thanks for the tip. All updated to explicit settings: Port 993, Use TLS/SSL, Authentication: Password. In looking at them (I have multiple email accounts), when I unchecked “automatically detect”, some said Port 993 and others said Port 143 even though all said Use TLS/SSL. While port 143 is the unencrypted IMAP port, I’m hoping it was still doing encrypted but yet another case of where Apple’s “it just works” can get in the way of making sure things are set the way you want them. Now to check my iOS devices. And now back to Postfix as IMAP is really off-topic for this list. -- Larry Stone lston...@stonejongleux.com > On Aug 6, 2019, at 2:17 PM, Peter wrote: > > On 7/08/19 2:02 AM, Larry Stone wrote: >> I use MacOS Mail and for receiving, I just have “Automatically manage >> connection settings” checked and it just works (but that’s really a Dovecot >> question, not Postfix). >> For sending, I do not have “Automatically manage connection settings” >> checked. Port is 587, Use TLS/SSL is checked, and Authentication is >> Password. But the correct settings for your server may be different. > > Just a bit of a possible "heads up" on this, but if your MUA has a setting to > automatically detect and use STARTTLS (and you use that setting) then you're > setting yourself up for a MITM attack vector where the MITM can downgrade > your connection to plain text and the MUA will not let you know. > > Years ago Thunderbird used to have a similar setting (Use Encryption if > available or something like that) but for years now they no longer offer it, > probably due to similar security concerns. > > > Peter
Re: Question getting Mail.app working with PostFix SMTP
> > On Aug 6, 2019, at 8:32 AM, John Dale > wrote: > > Greetings; > > I have Thunderbird working with PostFix/Dovecot for sending and receiving. > > STARTTLS > > Normal Password > > I don't see these options in Mail.app for OSX. > > I've tried updating ports and different combinations of available > authentication in Mail.app, but no luck. It either times-out or has > connection denied. > > Any recommendations? I use MacOS Mail and for receiving, I just have “Automatically manage connection settings” checked and it just works (but that’s really a Dovecot question, not Postfix). For sending, I do not have “Automatically manage connection settings” checked. Port is 587, Use TLS/SSL is checked, and Authentication is Password. But the correct settings for your server may be different. It may seem silly to ask but make sure you didn’t make a typo in the server name. -- Larry Stone lston...@stonejongleux.com
Re: logfile support for MacOS
> On Jan 23, 2019, at 1:29 PM, Wietse Venema wrote: > > Larry, can you insert one line in src/util/msg_logger.c, > or apply the patch at the end of this message? Wietse, thanks - that did it! I’m seeing the timestamps I expect. With reference to the earlier notes, I do not have the expertise to argue one way or the other about MacOS doing something weird. But it should not have been any power-saving / battery issue as this was on a desktop iMac. If your patch just works around another MacOS weirdness, thanks. For the record, I have tested the patch both on the my server (a 2010 iMac running High Sierra (10.13) as it is too old for Mojave) and my 2012 MacBookPro running Mojave (10.14). Both had the same issue and both now look good with the patch. Log extract: Started at 14:04:26, two test messages sent at 14:07:16 and 14:07:22, and then a postfix reload at 14:09:28. All looks correct: Jan 23 14:04:26 albion postfix/postfix-script[71395]: starting the Postfix mail system Jan 23 14:04:26 albion postfix/master[71397]: daemon started -- version 3.4-20190121-nonprod, configuration /usr/local/etc/postfix Jan 23 14:07:16 albion postfix/pickup[71398]: 7A3DD10343F8: uid=501 from= Jan 23 14:07:16 albion postfix/cleanup[71457]: 7A3DD10343F8: message-id=<20190123200716.7a3dd1034...@albion.stonejongleux.com> Jan 23 14:07:16 albion postfix/qmgr[71399]: 7A3DD10343F8: from=, size=468, nrcpt=1 (queue active) Jan 23 14:07:16 albion postfix/smtp[71460]: Anonymous TLS connection established to smtp.your-site.com[205.233.73.98]:587: TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits) Jan 23 14:07:17 albion postfix/smtp[71460]: 7A3DD10343F8: to=, relay=smtp.your-site.com[205.233.73.98]:587, delay=0.63, delays=0.04/0.05/0.37/0.16, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 43lGXh6s5wz10N1) Jan 23 14:07:17 albion postfix/qmgr[71399]: 7A3DD10343F8: removed Jan 23 14:07:21 albion postfix/pickup[71398]: E856410343FA: uid=501 from= Jan 23 14:07:21 albion postfix/cleanup[71457]: E856410343FA: message-id=<20190123200721.e85641034...@albion.stonejongleux.com> Jan 23 14:07:21 albion postfix/qmgr[71399]: E856410343FA: from=, size=468, nrcpt=1 (queue active) Jan 23 14:07:22 albion postfix/smtp[71460]: Anonymous TLS connection established to smtp.your-site.com[205.233.73.98]:587: TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits) Jan 23 14:07:22 albion postfix/smtp[71460]: E856410343FA: to=, relay=smtp.your-site.com[205.233.73.98]:587, delay=0.51, delays=0/0/0.36/0.14, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 43lGXp2P8lz10g1) Jan 23 14:07:22 albion postfix/qmgr[71399]: E856410343FA: removed Jan 23 14:09:28 albion postfix/postfix-script[71490]: refreshing the Postfix mail system Jan 23 14:09:28 albion postfix/master[71397]: reload -- version 3.4-20190121-nonprod, configuration /usr/local/etc/postfix -- Larry Stone lston...@stonejongleux.com
Re: logfile support for MacOS
Disregard. Reposted in the proper topic. -- Larry Stone lston...@stonejongleux.com > On Jan 23, 2019, at 10:35 AM, Larry Stone wrote: > > I noticed what appears to be a cosmetic problem: log entries from master are > being time-stamped with the time they were last started or “postfix > reload”-ed rather than the current time and log entries from qmgr are being > time-stamped with the time of the first activity since the start or reload.
Re: Postfix logging without syslogd
Oops. Inadvertently posted this reply in the wrong topic. Reposting it hear for proper threading. === I noticed what appears to be a cosmetic problem: log entries from master are being time-stamped with the time they were last started or “postfix reload”-ed rather than the current time and log entries from qmgr are being time-stamped with the time of the first activity since the start or reload. I did a postfix reload this morning while debugging my log file rotate/compress job: Jan 23 07:16:00 albion postfix/postfix-script[61552]: refreshing the Postfix mail system Jan 22 14:43:45 albion postfix/master[45505]: reload -- version 3.4-20190121-nonprod, configuration /usr/local/etc/postfix ^^^ time of last reload Jan 23 07:30:10 albion postfix/pickup[61558]: 9C59C1032D4E: uid=501 from= Jan 23 07:30:10 albion postfix/cleanup[61784]: 9C59C1032D4E: message-id=<20190123133010.9c59c1032...@albion.stonejongleux.com> Jan 23 07:30:10 albion postfix/qmgr[61559]: 9C59C1032D4E: from=, size=1041, nrcpt=1 (queue active) Jan 23 07:30:11 albion postfix/smtp[61792]: Anonymous TLS connection established to smtp.your-site.com[205.233.73.98]:587: TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits) Jan 23 07:30:11 albion postfix/smtp[61792]: 9C59C1032D4E: to=, relay=smtp.your-site.com[205.233.73.98]:587, delay=0.88, delays=0.12/0.16/0.44/0.16, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 43l5kW2zJ5zycF) Jan 23 07:30:10 albion postfix/qmgr[61559]: 9C59C1032D4E: removed Jan 23 07:30:10 albion postfix/pickup[61558]: 2AF4E1032E6B: uid=501 from= Jan 23 07:55:36 albion postfix/cleanup[62203]: 2AF4E1032E6B: message-id=<20190123135536.2af4e1032...@albion.stonejongleux.com> Jan 23 07:30:10 albion postfix/qmgr[61559]: 2AF4E1032E6B: from=, size=843, nrcpt=1 (queue active) ^^^ time of first activity above And from a few minutes ago to provide some greater time separation from the last reload: Jan 23 10:31:00 albion postfix/pickup[64766]: C81A61033C87: uid=501 from= Jan 23 10:31:00 albion postfix/cleanup[64795]: C81A61033C87: message-id=<20190123163100.c81a61033...@albion.stonejongleux.com> Jan 23 07:30:10 albion postfix/qmgr[61559]: C81A61033C87: from=, size=1590, nrcpt=1 (queue active) ^^^ time of first activity above Jan 23 10:31:01 albion postfix/smtp[64798]: Anonymous TLS connection established to smtp.your-site.com[205.233.73.98]:587: TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits) Jan 23 10:31:01 albion postfix/smtp[64798]: C81A61033C87: to=, relay=smtp.your-site.com[205.233.73.98]:587, delay=0.63, delays=0.05/0.03/0.43/0.11, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 43l9l92Zkzz16xT) Jan 23 07:30:10 albion postfix/qmgr[61559]: C81A61033C87: removed ^^^ time of first activity above -- Larry Stone lston...@stonejongleux.com > On Jan 22, 2019, at 6:20 AM, Wietse Venema wrote: > > Viktor Dukhovni: >> On Mon, Jan 21, 2019 at 07:04:56PM -0500, Wietse Venema wrote: >> >>> postfix-3.4-20190121-nonprod-logger has lightly-tested code for >>> logging to file without using syslogd. >> >> I see that the postlogd(8) service correctly uses a unix-dgram >> service to avoid message reordering, so the usual attention to >> detail has not deserted you. :-) Thanks! > > A lot of attention to detail went into this, but I have no control > over how the kernel's unix-domain datagram implementation buffers > messages until the postlogd service is ready. That's why messages > are time-stamped by the sender, not receiver. > >> For log rotation instructions, I would add that the old file should >> not be modified, compressed or otherwise assumed complete, until a >> new file is observed to have been written by postlogd(8) after >> processing the "reload" command. If one is not sure whether Postfix >> is running, one could use postlog(1) (as root) to cause a new file >> to be written, one way or the other. > > The Postfix master immediately signals postlogd to terminate. This > being a single-instance event-driven service, it should terminate > immediately unless it is blocked on file writes. > >> The only other nit that comes to mind, is that some syslog servers >> needlessly delete and re-create their unix-dgram sockets on reload, >> which leads to needless opportunities for brief loss of messages >> written to the previous incarnation of the socket. > > The Postfix master does not close a socket, unless the service is > removed from master.cf, or master_service_disable is in effect. > > Wietse
Re: logfile support for MacOS
I noticed what appears to be a cosmetic problem: log entries from master are being time-stamped with the time they were last started or “postfix reload”-ed rather than the current time and log entries from qmgr are being time-stamped with the time of the first activity since the start or reload. I did a postfix reload this morning while debugging my log file rotate/compress job: Jan 23 07:16:00 albion postfix/postfix-script[61552]: refreshing the Postfix mail system Jan 22 14:43:45 albion postfix/master[45505]: reload -- version 3.4-20190121-nonprod, configuration /usr/local/etc/postfix ^^^ time of last reload Jan 23 07:30:10 albion postfix/pickup[61558]: 9C59C1032D4E: uid=501 from= Jan 23 07:30:10 albion postfix/cleanup[61784]: 9C59C1032D4E: message-id=<20190123133010.9c59c1032...@albion.stonejongleux.com> Jan 23 07:30:10 albion postfix/qmgr[61559]: 9C59C1032D4E: from=, size=1041, nrcpt=1 (queue active) Jan 23 07:30:11 albion postfix/smtp[61792]: Anonymous TLS connection established to smtp.your-site.com[205.233.73.98]:587: TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits) Jan 23 07:30:11 albion postfix/smtp[61792]: 9C59C1032D4E: to=, relay=smtp.your-site.com[205.233.73.98]:587, delay=0.88, delays=0.12/0.16/0.44/0.16, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 43l5kW2zJ5zycF) Jan 23 07:30:10 albion postfix/qmgr[61559]: 9C59C1032D4E: removed Jan 23 07:30:10 albion postfix/pickup[61558]: 2AF4E1032E6B: uid=501 from= Jan 23 07:55:36 albion postfix/cleanup[62203]: 2AF4E1032E6B: message-id=<20190123135536.2af4e1032...@albion.stonejongleux.com> Jan 23 07:30:10 albion postfix/qmgr[61559]: 2AF4E1032E6B: from=, size=843, nrcpt=1 (queue active) ^^^ time of first activity above And from a few minutes ago to provide some greater time separation from the last reload: Jan 23 10:31:00 albion postfix/pickup[64766]: C81A61033C87: uid=501 from= Jan 23 10:31:00 albion postfix/cleanup[64795]: C81A61033C87: message-id=<20190123163100.c81a61033...@albion.stonejongleux.com> Jan 23 07:30:10 albion postfix/qmgr[61559]: C81A61033C87: from=, size=1590, nrcpt=1 (queue active) ^^^ time of first activity above Jan 23 10:31:01 albion postfix/smtp[64798]: Anonymous TLS connection established to smtp.your-site.com[205.233.73.98]:587: TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits) Jan 23 10:31:01 albion postfix/smtp[64798]: C81A61033C87: to=, relay=smtp.your-site.com[205.233.73.98]:587, delay=0.63, delays=0.05/0.03/0.43/0.11, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 43l9l92Zkzz16xT) Jan 23 07:30:10 albion postfix/qmgr[61559]: C81A61033C87: removed ^^^ time of first activity above -- Larry Stone lston...@stonejongleux.com > On Jan 19, 2019, at 3:10 PM, John Stoffel wrote: > >>>>>> "Wietse" == Wietse Venema writes: > > Wietse> John Stoffel: >>>>>>>> "Wietse" == Wietse Venema writes: >>> > Wietse> I'm implementing logfile support for Postfix on MacOS, because not > Wietse> providing results in a bad experience. >>> > Wietse> This is a retrofit workaround, therefore it will have limitations > Wietse> that do not exist with the default syslog-based implementation. >>> >>> Why not just provide a syslog daemon configured for only Postfix use >>> on MACs? > > Wietse> Sorry, I will not support syslogd or other non-Postfix programs. > > I can understand that, but I was more thinking of writing a syslogd > compatible receiver for macOS, so that you dno't have to change all > the rest of the postfix base. Yes, it's not ideal, but supporting > MACs isn't ideal these days either. > > John >
Re: Fixing open relay problem
On Jan 22, 2019, at 1:30 AM, Dominic Raferd wrote: > > On Tue, 22 Jan 2019 at 06:22, Stephen McHenry > wrote: >> (and from postconf -d) >> smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated, >> defer_unauth_destination >> >> > I think you are just lucky that this didn't happen till now. Note that > postconf -d just shows the defaults, not what you are using. > Yes. Please shows us the postconf -n value of smtpd_relay_restrictions > My approach (a typical one I think) is to block all emails with envelope > sender @mydomain.com unless the client has authenticated via port 465 or 587: Not so typical IMHO. And probably unneeded to solve the OP’s problem. Once we see what he really had in smtp_relay_restrictions, we are likely to find a simple issue there that he can easily fix. -- Larry Stone lston...@stonejongleux.com
Re: Postfix logging without syslogd
On Jan 21, 2019, at 6:04 PM, Wietse Venema wrote: > > postfix-3.4-20190121-nonprod-logger has lightly-tested code for > logging to file without using syslogd. > I just successfully built it on a Mojave system and so far, all looks good. One test email sent out (my Postfix is outgoing only) was properly logged. Have not tested anything yet involving log rotation. Unlike James Brown and his Unsupported Berkeley DB version, I do not have Berkeley DB on my system (unless a version comes with MacOS), do not use mySQL, and do not have anything from Homebrew on the system. -- Larry Stone lston...@stonejongleux.com
Re: logfile support for MacOS
On Jan 18, 2019, at 2:18 PM, Wietse Venema wrote: > I'm implementing logfile support for Postfix on MacOS, because not > providing results in a bad experience. Wietse, I’m impressed. As I run Postfix on a couple of Macs in a non-critical environment (outgoing only for messages from system processes and monitoring jobs), I’ll be happy to do some testing when you have it ready. -- Larry Stone lston...@stonejongleux.com
Re: Upgraded to 3.4 today. All logging has Stopped?
> > On Jan 10, 2019, at 11:08 AM, Wietse Venema wrote: > > If both Dovecot and Postfix write to the same logfile, that would > be a disaster. > Thanks to Wietse for that detailed explanation of all the issues involved with attempting to roll your own logging system. Lots of issues I never thought about and as a result, my knowledge of the subject has been greatly expanded. -- Larry Stone lston...@stonejongleux.com
Re: Upgraded to 3.4 today. All logging has Stopped?
> On Jan 9, 2019, at 9:48 PM, James Brown wrote: > >> On 10 Jan 2019, at 2:01 pm, Larry Stone wrote: >> >> Is this a recent build of Dovecot or was it built on an older version of >> MacOS before the logging changes? If the former, ask on the Dovecot list how >> they did it. If the latter, it’s a meaningless data point until Dovecot is >> rebuilt on a newer version of MacOS. >> > > Hi Larry. It’s a recent build of Dovecot, compiled on Mojave. ... > > The setting file for logging, “etc/dovecot/conf.d/10-logging.conf” does have > this: > > ## > ## Log destination. > ## > > # Log file to use for error messages. "syslog" logs to syslog, > # /dev/stderr logs to stderr. > #log_path = syslog > log_path = /var/log/mail.log > > So I’ve had to change this so that it writes directly to the file, and not to > syslog. Ah. So Dovecot has the ability to write logs directly. I believe Wietse has stated in the past that no such capability exists in Postfix and it only logs to the syslog daemon. And it’s the changes Apple has made to syslog that are the issue. Bill Cole posted (again) a workaround that you can pursue. Beyond that, unless Wietse decides to modify Postfix’s logging to support alternate methods such as Dovecot does (and I have not the slightest clue how involved that might be - you’re welcome to do it yourself if you’re so inclined), we really don’t have a solution given Apple’s decision to move away from the Unix standard for logging. Bill also stated that MacOS is no longer a suitable platform for being a server and I largely concur. I used to run a full mail server but gave up on that three years ago and moved my mail to an outside service (and as I now have a provider that blocks port 25, not an option for me anymore anyway). I still run Postfix but only for getting system generated emails off the system to my outside mail service (I have some system status processes that alert me to various issues that can occur) so logging is not the concern for me today that it was when I was running the full server. -- Larry Stone lston...@stonejongleux.com
Re: Upgraded to 3.4 today. All logging has Stopped?
On Jan 9, 2019, at 19:01, James Brown wrote: > > Thanks Viktor. It would be great if Postfix would log to disk on newer > versions of macOS X like it did before. My Mojave test mail server has > Dovecot logging to /var/log/mail.log but Postfix doesn’t. Is this a recent build of Dovecot or was it built on an older version of MacOS before the logging changes? If the former, ask on the Dovecot list how they did it. If the latter, it’s a meaningless data point until Dovecot is rebuilt on a newer version of MacOS. > Has anyone managed to do this? I’d rather not have to compile on old Mac and > transfer. Not as far as any of us know. It’s been discussed here before and no solution has been found. — Larry Stone lston...@stonejongleux.com
Re: How do I get 'mail' working again
> On Dec 28, 2018, at 11:41 AM, Viktor Dukhovni
> wrote:
>
> You don't need to do this, that will break every upgrade, and changing
> it requires to disable Apple's system-integrity protection (at least
> temporarily, and reboot to change it back and forth).
>
> Instead, it is sufficient to:
>
> Build your Postfix with binaries in
> /usr/local/{sbin,libexec/postfix,lib/postfix}, *but*
> configuration in /etc/postfix. Leave /usr/sbin/sendmail alone.
> …
Hmmm. Viktor, in the past, I thought you said it is sufficient to merely have
both the Apple Postfix and your own Postfix have the same queue_directory.
That’s how I have mine set up and it works the way I need it to work -
/usr/sbin/sendmail (Apple’s sendmail) drops the file in queue_directory
whereupon my locally built Postfix grabs it and sends it on its way. I have not
made the four directories you mentioned the same.
--
Larry Stone
lston...@stonejongleux.com
Re: New install - Temporary lookup failures when trying to send
> On Dec 6, 2018, at 3:00 AM, Matus UHLAR - fantomas wrote: > >> On Mon Dec 03 2018 04:27:43 Matus UHLAR - fantomas >> said: >>> pleaase, get a decent MUA, not applemail that tries to encode everything as >>> internet links (and messes up thge plaintext version of mail). > > On 04.12.18 13:47, @lbutlr wrote: >> What do you base this statement on? I’ve been using Apple’s Meal.app since >> around 2003 or so, and I’ve never had it encode everything as Internet >> links more mess up plaintext mail. > > based on sender's > X-Mailer: Apple Mail (2.3445.102.3) > > and the result I have quoted that is also visible on: > > https://marc.info/?l=postfix-users&m=154380074926895&w=2 > > the HTML parts may be encoded properly, but the plaintext version of sent > mail contains useless crap where > > > > is converted to: > > mailto:jlbr...@bordo.com.au>> > > and: > > mail.bordo.com.au > > is converted to: > > mail.bordo.com.au <http://mail.bordo.com.au/> That does not appear to be the standard Apple Mail. I am running MacOS 10.14.1 (the latest until 10.14.2 was released yesterday) and I have Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\)) X-Mailer: Apple Mail (2.3445.101.1) while jlbr...@bordo.com.au has Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) X-Mailer: Apple Mail (2.3445.102.3) It’s possible that’s a new version included with 10.14.2 but Mr. Brown sent his message four days ago and 10.14.2 was released yesterday (he might have been running a pre-release version). It’s possible that however he pasted that into his message did that. It’s also possible that something downline of Mr. Brown at bordo.com.au is changing the message, converting it to multi-part, and adding that crap. I do note in the headers of his message that there are a bunch related to an anti-spam product called ASSP. I’ve never heard of it before and have no idea if it has that capability. X-Assp-Version: 2.6.2(18328) on mail.bordo.com.au X-Assp-ID: mail.bordo.com.au id-00682-15042 X-Assp-Session: 7FB04622FB68 (mail 1) X-Assp-Envelope-From: jlbr...@bordo.com.au X-Assp-Intended-For: postfix-users@postfix.org X-Assp-Client-SSL: yes X-Assp-Server-TLS: yes In any event, unless I’m missing it, the version I and most everyone else has of Apple Mail does not do that. I’ve sent a test message to myself with HTML included and there was no conversion of links. And this message was sent with Apple Mail. -- Larry Stone lston...@stonejongleux.com
Re: New install - Temporary lookup failures when trying to send
> On Dec 4, 2018, at 2:47 PM, @lbutlr wrote: > > On Mon Dec 03 2018 04:27:43 Matus UHLAR - fantomas > said: >> >> pleaase, get a decent MUA, not applemail that tries to encode everything as >> internet links (and messes up thge plaintext version of mail). > > What do you base this statement on? I’ve been using Apple’s Meal.app since > around 2003 or so, and I’ve never had it encode everything as Internet links > more mess up plaintext mail. Agree. I’ve been using Apple Mail for many years as well and never seen it do that either. This email was sent by Apple Mail and I don’t believe you’ll see anything weird done to it. -- Larry Stone lston...@stonejongleux.com
Re: How do I turn on logging for postfix on mac
> On Nov 8, 2018, at 2:42 AM, James Brown wrote: > > I’ve been having the same issue. Apple changed their logging system a few > releases ago (Sierra?) to use the Unified Logging System, which logs to RAM > rather than disk files. It’s been discussed here before. And so far, no one has come up with a way to build on a current MacOS version and have it log to /var/log/mail.log. > I have heard of someone compiling Postfix an an older Mac, then moving it > across to Mojave and it then logs to /var/log/mail.log. Viktor did suggest that a while back and it does work. I have an old Macintosh running MacOS 10.9.5 in order to support a fax modem and I do the Postfix builds on it as well. > Hopefully someone knows how to bring back the old functionality. > So far, no. Apple knows what’s best for us. :-( Also, please don’t top post on this list. Replies should be interleaved with the lines you are replying to. -- Larry Stone lston...@stonejongleux.com > James. > >> On 8 Nov 2018, at 6:57 pm, Robert Chalmers wrote: >> >> I have been asked how I turn on /var/log/mail.log for postfix on a Mac >> running Mohave. >> >> I have it running on mine, but it always has - but I can’t remember if I had >> to do anything special to turn it on. >> The person asking has no /var/log/mail.log at all and now I’m curious. >> >> thanks >> robert >
Re: macOS X, Operation not permitted - rename sendmail
> On Oct 1, 2018, at 3:13 AM, Viktor Dukhovni > wrote: > > On Mon, Oct 01, 2018 at 05:56:57PM +1000, James Brown wrote: > >> I’ve just tired to install Postfix 3.3.1 on macOS X 10.13.6 High Sierra. >> >> Sudo make install finishes with: >> >> Updating /usr/sbin/sendmail... > > In MacOSX /usr is immutable, except during upgrade reboots. You > can't install Postfix in /usr. You need to build it for installation > in /usr/local. This also means you can't replace /usr/sbin/sendmail, Not quite. If you turn off SIP (System Integrity Protection), you can modify /usr. I’ve been running with SIP off since shortly after Apple added that feature. So far, they haven’t added anything that gets upset with you for doing so. Although when Apple had their hands on my MacBookPro to replace the battery, I found they turned it back on. > MacOS/X is no longer a good platform for running your own Postfix > builds, the other major obstacle is that getting usable logs is is > painfully different. You're running Postfix on a system that is > not designed to be a server. Agree. As I like to say, Apple thinks they know best how you should be using their products - there’s the “Apple Way” and the “wrong way” with nothing in between. I build Postfix (which I use only for outbound system messages) on an old MacOS 10.9 system and then transfer the build. That keeps logging working the “right” way but is obviously not a long-term viable solution. Not concerned about having the latest and greatest Postfix since it’s not externally accessible. -- Larry Stone lston...@stonejongleux.com
Re: Cyrus vs Dovecot for SASL AUTH and IMAP
> On Jan 16, 2018, at 11:26 PM, Patrick Ben Koetter wrote: > > The Cyrus SASL project has been discontinued. I recommend not to use security > relevant software that is unmaintained. Use Dovecot as password verification > service for Postfix. There seems to still be activity. I am subscribed to the Cyrus SASL email list and there was a new RC release recently. Things seem to move slowly there but things seem to be happening. Unfortunately, the last I knew, Dovecot is only supported by Postfix for inbound authentication. Outbound authentication (e.g. relaying outbound mail through an upstream server) requires Cyrus. -- Larry Stone lston...@stonejongleux.com
Re: MacOS High Sierra (10.13) and Postfix relaying
Exactly although Postfix stuff should go to /var/log/mail.log (mine does). It was Viktor who suggested doing that - he’s much more an expert on the internals involved. I build (make) on 10.9.5, then tar the directory, copy it to the target system, untar, and then make upgrade. Works fine although I’m sure there’s some things Postfix is dependent on that needs to be on both. I know Viktor was interested in the logging issues but didn’t have time to dig into it but the recent thread about logging tells me as Postfix depends on system logging, the only way to avoid Apple’s unified logging would be to build your own log handler. But that’s something that is way beyond me. -- Larry Stone lston...@stonejongleux.com > On Nov 6, 2017, at 12:10 PM, James Reynolds wrote: > > Larry, > Can you explain what you mean by the current Apple logging system? You mean > the unified logging? Are you avoiding this by building postfix on 10.9.5 and > then copying it to a 10.12+ computer so that it logs to /var/log/system.log > instead? You haven't had any other problems doing this? > > I ask because I need to update my mail server that's running on macos. > > James Reynolds > Sr Systems Administrator > Department of Biology > The University of Utah > 801-585-3086 > >> On Oct 27, 2017, at 6:45 AM, Larry Stone wrote: >> >> I have run a test upgrade to High Sierra and Postfix ran fine. I currently >> only use Postfix to relay mail generated by system services on the Macintosh >> to my external mail service. Postfix started fine and a test message was >> sent using the sendmail command which made it out. >> >> Postfix version is the latest 3.2.3. However, due to the current Apple >> logging system, I build (make) Postfix on an older system running the final >> version of Mavericks (10.9.5) and then copy the build directory to the >> target system to run make upgrade. >> >> -- >> Larry Stone >> lston...@stonejongleux.com >> >> >> >> >> >>> On Oct 27, 2017, at 5:11 AM, sergio.pozzetti wrote: >>> >>> Hi all, >>> >>> I use postfix to relay e-mail to a Google Account, which has been working >>> flawlessly up until now. >>> I'm running out of options here. After upgrading to MacOS High Sierra, >>> postfix simply won't start: >>> >>> sh-3.2# postfix -v start >>> postfix: name_mask: ipv4 >>> postfix: inet_addr_local: configured 2 IPv4 addresses >>> postfix: Postfix is running with backwards-compatible default settings >>> postfix: See http://www.postfix.org/COMPATIBILITY_README.html for details >>> postfix: To disable backwards compatibility use "postconf >>> compatibility_level=2" and "postfix reload" >>> postfix/postfix-script: starting the Postfix mail system >>> postfix/postfix-script: fatal: mail system startup failed >>> >>> All I get in /var/log/mai.log aside from this is "fatal: daemon >>> initialization failure". >>> >>> (1) I can't figure out where postfix might be dumping more information; >>> (2) I didn't change anything in my main.cf other than commenting out >>> "mydomain_fallback = localhost" which was apparently deprecated. >>> >>> Other than that my postconf -n output looks like this: >>> >>> biff = no >>> command_directory = /usr/sbin >>> daemon_directory = /usr/libexec/postfix >>> data_directory = /var/lib/postfix >>> debug_peer_level = 2 >>> debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin ddd >>> $daemon_directory/$process_name $process_id & sleep 5 >>> html_directory = /usr/share/doc/postfix/html >>> inet_protocols = ipv4 >>> mail_owner = _postfix >>> mailbox_size_limit = 0 >>> mailq_path = /usr/bin/mailq >>> manpage_directory = /usr/share/man >>> message_size_limit = 10485760 >>> mynetworks = 127.0.0.0/8, [::1]/128 >>> newaliases_path = /usr/bin/newaliases >>> queue_directory = /private/var/spool/postfix >>> readme_directory = /usr/share/doc/postfix >>> recipient_delimiter = + >>> relayhost = smtp.gmail.com:587 >>> sample_directory = /usr/share/doc/postfix/examples >>> sendmail_path = /usr/sbin/sendmail >>> setgid_group = _postdrop >>> smtp_sasl_auth_enable = yes >>> smtp_sasl_mechanism_filter = login >>> smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd >>> smtp_sasl_security_options = noanonymous >>> smtp_tls_security_level = encrypt >>> smtp_use_tls = yes >>> smtpd_client_restrictions = permit_mynetworks permit_sasl_authenticated >>> permit >>> smtpd_tls_ciphers = medium >>> tls_random_source = dev:/dev/urandom >>> unknown_local_recipient_reject_code = 550 >>> >>> Any help would be appreciated. >>> >>> -- >>> Sergio >>> >>> >>> >>> -- >>> Sent from: http://postfix.1071664.n5.nabble.com/Postfix-Users-f2.html >> > > > >
Re: MacOS High Sierra (10.13) and Postfix relaying
I have run a test upgrade to High Sierra and Postfix ran fine. I currently only use Postfix to relay mail generated by system services on the Macintosh to my external mail service. Postfix started fine and a test message was sent using the sendmail command which made it out. Postfix version is the latest 3.2.3. However, due to the current Apple logging system, I build (make) Postfix on an older system running the final version of Mavericks (10.9.5) and then copy the build directory to the target system to run make upgrade. -- Larry Stone lston...@stonejongleux.com > On Oct 27, 2017, at 5:11 AM, sergio.pozzetti wrote: > > Hi all, > > I use postfix to relay e-mail to a Google Account, which has been working > flawlessly up until now. > I'm running out of options here. After upgrading to MacOS High Sierra, > postfix simply won't start: > > sh-3.2# postfix -v start > postfix: name_mask: ipv4 > postfix: inet_addr_local: configured 2 IPv4 addresses > postfix: Postfix is running with backwards-compatible default settings > postfix: See http://www.postfix.org/COMPATIBILITY_README.html for details > postfix: To disable backwards compatibility use "postconf > compatibility_level=2" and "postfix reload" > postfix/postfix-script: starting the Postfix mail system > postfix/postfix-script: fatal: mail system startup failed > > All I get in /var/log/mai.log aside from this is "fatal: daemon > initialization failure". > > (1) I can't figure out where postfix might be dumping more information; > (2) I didn't change anything in my main.cf other than commenting out > "mydomain_fallback = localhost" which was apparently deprecated. > > Other than that my postconf -n output looks like this: > > biff = no > command_directory = /usr/sbin > daemon_directory = /usr/libexec/postfix > data_directory = /var/lib/postfix > debug_peer_level = 2 > debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin ddd > $daemon_directory/$process_name $process_id & sleep 5 > html_directory = /usr/share/doc/postfix/html > inet_protocols = ipv4 > mail_owner = _postfix > mailbox_size_limit = 0 > mailq_path = /usr/bin/mailq > manpage_directory = /usr/share/man > message_size_limit = 10485760 > mynetworks = 127.0.0.0/8, [::1]/128 > newaliases_path = /usr/bin/newaliases > queue_directory = /private/var/spool/postfix > readme_directory = /usr/share/doc/postfix > recipient_delimiter = + > relayhost = smtp.gmail.com:587 > sample_directory = /usr/share/doc/postfix/examples > sendmail_path = /usr/sbin/sendmail > setgid_group = _postdrop > smtp_sasl_auth_enable = yes > smtp_sasl_mechanism_filter = login > smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd > smtp_sasl_security_options = noanonymous > smtp_tls_security_level = encrypt > smtp_use_tls = yes > smtpd_client_restrictions = permit_mynetworks permit_sasl_authenticated > permit > smtpd_tls_ciphers = medium > tls_random_source = dev:/dev/urandom > unknown_local_recipient_reject_code = 550 > > Any help would be appreciated. > > -- > Sergio > > > > -- > Sent from: http://postfix.1071664.n5.nabble.com/Postfix-Users-f2.html
Re: Virtual Domains/ Users
> On Oct 26, 2017, at 16:29, cac...@quantum-equities.com wrote: > I am surprised with this sprawl, in the 21st Century. In 30 minutes I've > figured out and implemented DKIM. But it appears to me that Postfix has > evolved organically (Read: disorganized) as have many legacy applications > like Apache used to be. The documentation you refer to is there alright, but > it's all about bit-twiddling, nothing about concepts and methodologies. You > have to start with the big ideas first, and -then- work your way down, not > regard potential admins as unworthy for not knowing the vapors. So much > information that you here take for granted, is simply unsaid in the docs, and > I can't swirl up my mind into a vortex and reach out to suck in the knowledge > from your brains with telepathy. > Postfix documentation documents Postfix; it does not attempt to document SMTP and assumes the reader has a basic understanding of SMTP. Similarly, your car’s owner’s manual documents your car; it does not teach you how to drive and Word’s documentation documents Word and does not teach you how to write. -- Larry Stone Sent from my iPad
Re: how to remove string "[MASSMAIL]" from the subject ?
Neither do I as you have provided no information about your Postfix configuration or anything else. As it says in the Postfix list welcome email you received: TO REPORT A PROBLEM see http://www.postfix.org/DEBUG_README.html#mail But if you’ve verified Mailman is not adding it as a list prefix tag, then you need to tell us what else is handling the email before it makes it to your mailbox. Also, reply on list, not directly to me. Future emails sent directly to me will be ignored. -- Larry Stone lston...@stonejongleux.com > On Mar 31, 2017, at 6:03 AM, Zalezny Niezalezny > wrote: > > hi larry, > > i have removed prefix but for some list system simply adding this prefix.i > dnt know what to do. > > Any how it would be great to know how to remove that string with postfix. > > > cheers > > zalezny > > 31 mar 2017 12:58 "Larry Stone" napisał(a): > This is a Mailman mailing list you run? That Mailman has the option to add a > tag in front of the subject (and it’s not the default so you would have had > to explicitly turn it on). There is a Mailman-users mailing list and that > would be the appropriate place for help. > > But, since it says [MASSMAIL] and MASS implies to me that it’s to indicate > that it’s being sent to a MASS of recipients, it sounds like it might be a > mail filter downline of Mailman that, for instance, sees the “Precedence: > bulk” header and tags the mail. In which case Mailman has nothing to do with > it. > > In any event, the [MASSMAIL] tag is a symptom of some other problem adding > the undesired (to you at least) tag. Fix the problem, not the symptom. > > -- > Larry Stone > lston...@stonejongleux.com > > > > > > > On Mar 31, 2017, at 5:32 AM, Zalezny Niezalezny > > wrote: > > > > Hi, > > > > will it be possible to remove string [MASSMAIL] from outgoing E-mails ? > > > > > > From: bla!@firma.com > > to: *@gmail.com > > Subject: [MASSMAIL] text of the messages > > > > I would like to have some thing like this. > > > > From: bla!@firma.com > > to: *@gmail.com > > Subject: text of the messages > > > > > > Unfortunatelly Mailman adding this string to some of my mailing lists and I > > do not know how to change it, maybe it will be possible to rewrite it with > > Postfix ? > > > > > > > > Thanks in advance for any support. > > > > > > > > Cheeers > > > > Zalezn >
Re: how to remove string "[MASSMAIL]" from the subject ?
This is a Mailman mailing list you run? That Mailman has the option to add a tag in front of the subject (and it’s not the default so you would have had to explicitly turn it on). There is a Mailman-users mailing list and that would be the appropriate place for help. But, since it says [MASSMAIL] and MASS implies to me that it’s to indicate that it’s being sent to a MASS of recipients, it sounds like it might be a mail filter downline of Mailman that, for instance, sees the “Precedence: bulk” header and tags the mail. In which case Mailman has nothing to do with it. In any event, the [MASSMAIL] tag is a symptom of some other problem adding the undesired (to you at least) tag. Fix the problem, not the symptom. -- Larry Stone lston...@stonejongleux.com > On Mar 31, 2017, at 5:32 AM, Zalezny Niezalezny > wrote: > > Hi, > > will it be possible to remove string [MASSMAIL] from outgoing E-mails ? > > > From: bla!@firma.com > to: *@gmail.com > Subject: [MASSMAIL] text of the messages > > I would like to have some thing like this. > > From: bla!@firma.com > to: *@gmail.com > Subject: text of the messages > > > Unfortunatelly Mailman adding this string to some of my mailing lists and I > do not know how to change it, maybe it will be possible to rewrite it with > Postfix ? > > > > Thanks in advance for any support. > > > > Cheeers > > Zalezn
Re: How to get mail relay to work
Your original post did not indicate a problem you are having. The only question you asked was "Besides /etc/postfix/main.cf, is there any other files that need to be edited to enable this mail relaying?”. Was this an oblique way of saying “it’s not working, what else do I need to change” or are you just asking what else needs to be changed? It’s not clear if you’re still setting up the new system or if you’ve tried to run it and there’s a problem. The answer to your question is “master.cf as well as any files referenced in main.cf”. The better way to compare the main.cf files is to do a postconf -n on both. That displays only the parameters that have been changed from their defaults. Easier than scanning through a long main.cf looking for uncommented lines. OTOH, if you are trying to run it and it’s not working, providing more information as requested in the list’s welcome message will help. As it says there: TO REPORT A PROBLEM see http://www.postfix.org/DEBUG_README.html#mail That includes a list of what is required. -- Larry Stone lston...@stonejongleux.com > On Mar 17, 2017, at 7:36 AM, paul.greene.va > wrote: > > Maybe you're in an environment where you get to decide which equipment, > applications, whatever you want to use, but for some of us, this was already > decided long before we got there. We are using postfix for a mail server, > that's a given. I already admitted I'm very new to running a mail server; > this postfix mail server is not relaying email the way its supposed to. This > is a "support" mailing list, is it not? People ask questions on a postfix > support mailing list because they're trying to figure out how to get postfix > to work correctly. > > > On 3/16/2017 11:29 PM, D'Arcy Cain wrote: >> On 2017-03-16 09:34 PM, paul.greene.va wrote: >>> I've been given a task to get a freshly installed postfix server to >>> forward mail from an application - i.e. when changes are made to an >>> application, the application is supposed to send an email notification >>> to a specified email address. >> >> I'm not sure that this is even a Postfix question. I assume that there is >> some trigger in the application that handles changes. That application just >> needs to send an email. Whatever mail server you are using should be >> irrelevant. In fact, you could punt elsewhere and not have a mail server at >> all. >> >> Perhaps I am not understanding the challenge. >> >
Re: 3.1.4 Compiled and Installed on OSX Sierra 10.12.2 Successful.
> On Feb 18, 2017, at 10:39 AM, Larry Stone wrote: > >> >> On Feb 18, 2017, at 8:11 AM, Viktor Dukhovni >> wrote: >> > >> If you have a pre-Sierra MacOS/X machine, perhaps building 3.1.4 there >> and copying the binaries will yield the same behaviour you see with >> 3.1.1? > > I do but it’s all the way back at Mavericks (10.9.5). I recently > recommissioned an old MacBookPro (I never could get it to upgrade beyond > where it is) to use as a Fax Server since Sierra discontinued support for USB > Fax Modems. At some point, I’ll try building 3.1.4 there and see what happens > and if I can move the built files. Tried and it works. So now running 3.1.4 on Sierra with the build having been done on Mavericks. But now, and longer term, see if there’s a way to build under Sierra with the old syslog logging. -- Larry Stone lston...@stonejongleux.com
Re: 3.1.4 Compiled and Installed on OSX Sierra 10.12.2 Successful.
> On Feb 18, 2017, at 8:11 AM, Viktor Dukhovni > wrote: > > On Sat, Feb 18, 2017 at 07:37:27AM -1000, Larry Stone wrote: > >> Viktor, did you ever figure out the logging issue? > > No. Insufficient time to figure out the innards of the new Apple > logging subsystem. My laptop is just for Postfix development, so > the issue has not as yet warranted much effort on my part. > >> I just tried upgrading my test system to Postfix 3.1.4 (from 3.1.1) and >> the logging started to go to the new Apple logging system. Immediately >> fell back to 3.1.1 and the logging is back to /var/log/mail.log. > > Is the 3.1.1 build also your own? Built under the same O/S version? Arg! My usual approach to OS X upgrades is to first clone the disk and upgrade the copy as a test. I must have done my test rebuild of Postfix on the clone, saw that it was functional but missed the logging issue, then when I upgraded for real, never rebuilt Postfix since the old version built under El Capitan ran fine. Rebuilding 3.1.1 under Sierra also uses the new MacOS logging so fell back again to the El Capitan built version. > If you have a pre-Sierra MacOS/X machine, perhaps building 3.1.4 there > and copying the binaries will yield the same behaviour you see with > 3.1.1? I do but it’s all the way back at Mavericks (10.9.5). I recently recommissioned an old MacBookPro (I never could get it to upgrade beyond where it is) to use as a Fax Server since Sierra discontinued support for USB Fax Modems. At some point, I’ll try building 3.1.4 there and see what happens and if I can move the built files. But, I’m probably good with 3.1.1 for a long time. My Postfix is no longer Internet facing (I used to run my own mail server but now have that contracted out to an ISP) so I just use Postfix to get internally generated email (including the aforementioned fax server which emails incoming faxes) out to my ISP. -- Larry Stone lston...@stonejongleux.com
Re: 3.1.4 Compiled and Installed on OSX Sierra 10.12.2 Successful.
Viktor, did you ever figure out the logging issue? I just tried upgrading my test system to Postfix 3.1.4 (from 3.1.1) and the logging started to go to the new Apple logging system. Immediately fell back to 3.1.1 and the logging is back to /var/log/mail.log. My initial make command (based on what you’ve previously suggested is): make -f Makefile.init makefiles CCARGS='-DUSE_TLS -I/usr/local/ssl/include \ -DUSE_SASL_AUTH \ -DUSE_CYRUS_SASL \ -I/usr/local/include/sasl \ -DDEF_SERVER_SASL_TYPE=\"dovecot\"\ -DDEF_COMMAND_DIR=\"/usr/local/sbin\"\ -DDEF_CONFIG_DIR=\"/usr/local/etc/postfix\"\ -DDEF_DAEMON_DIR=\"/usr/local/libexec/postfix\"\ -DHAS_PCRE -I/usr/local/include' \ AUXLIBS='-L/usr/local/lib -lpcre -L/usr/local/ssl/lib -lssl -lcrypto \ -L/usr/local/lib -lsasl2’ -- Larry Stone lston...@stonejongleux.com > On Jan 3, 2017, at 6:51 AM, Larry Stone wrote: > > I seem to be missing a couple of messages in this thread but I upgraded my > laptop (I use it as a test system as well) to Sierra over the weekend and am > getting normal logging without doing anything special. My Postfix is in > /usr/local (I moved completely away from the Apple directories for the server > stuff I do). > > Postfix (I'm still on 3.1.1) ran as previously built (no need to re-make > under Sierra although I have tested that it builds OK) (in fact all the > server software I now run runs as previously built). > > So maybe the question is what did you (Viktor) do that is causing the > different logging format? Did you upgrade from El Capitan or is it a fresh > install? It looks like yours are going through Apple's new (and IMHO not as > good) log facility rather than syslog (that's the same format I see for > TimeMachine log messages extracted from the new log facility; e.g. > 2017-01-01 06:18:18.094145-0600 localhost backupd[13915]: (TimeMachine) > [com.apple.TimeMachine.TMLogInfo] Backup completed successfully. > > -- Larry Stone > lston...@stonejongleux.com > > On Tue, 3 Jan 2017, Viktor Dukhovni wrote: > >> >>> On Jan 3, 2017, at 10:33 AM, Robert Chalmers wrote: >>> >>> Do you mean like this ? where ?postfix? shows up.? >>> >>> Jan 3 09:58:20 zeus postfix/smtpd[31070]: connect from unknown[115.71.5.5] >> >> Yes. What did you do to get real syslog messages with MacOS/X Sierra? >> >>>> I get output similar to: >>>> >>>> 2017-01-03 10:11:13.946120-0500 localhost smtpd[7301]: >>>> (libpostfix-util.dylib) disconnect from localhost[127.0.0.1] ehlo=1 >>>> starttls=0/1 commands=1/2 >>>> >>>> In which the "postfix/" syslog_name is nowhere in sight. Makes >>>> multi-instance >>>> logging rather opaque, and breaks the usual way to distinguish submission >>>> logging >>>> from port 25 logging, ... >> >> -- >> Viktor. >> >>
Re: Postfix 20 years ago
I’ll add my thanks as well. Looking through my email archive, I first signed up for this list in 2008. As other have said, one of Postfix’s strengths is its excellent documentation which has led me to configure Postfix to meet my needs while understanding why it does that and how I can make it do other things if needed. OTOH, too much of other open source software has poor documentation that assumes you already know everything (in which case you have no need for the documentation :-( ) and with them, I have never felt like I have the level of knowledge to confidently make configuration changes (with Postfix, I know what the configuration does and I feel confident making changes; with the others, I have a configuration that meets my needs but I’m not quite sure why and I don’t dare even breathe on it out of a fear it will horribly break if I do). -- Larry Stone lston...@stonejongleux.com
Re: Postfix instance not listening
Mostly directed at the OP: I'm mostly a lurker here but I've learned a lot here. The tone of this list is mostly "teach a man to fish", not "give a man a fish" (from the old saying "give a man a fish and you feed him for a day; teach a man to fish and you feed him for life". To that end, answers tend to point out and explain how to solve the problem so that the questioner learns. Just providing the answer does not promote learning. Or to build on the adage above, giving the solution merely solves today's problem; teaching how Postfix works solves the future problems as well. -- Larry Stone lston...@stonejongleux.com
Re: 3.1.4 Compiled and Installed on OSX Sierra 10.12.2 Successful.
I seem to be missing a couple of messages in this thread but I upgraded my laptop (I use it as a test system as well) to Sierra over the weekend and am getting normal logging without doing anything special. My Postfix is in /usr/local (I moved completely away from the Apple directories for the server stuff I do). Postfix (I'm still on 3.1.1) ran as previously built (no need to re-make under Sierra although I have tested that it builds OK) (in fact all the server software I now run runs as previously built). So maybe the question is what did you (Viktor) do that is causing the different logging format? Did you upgrade from El Capitan or is it a fresh install? It looks like yours are going through Apple's new (and IMHO not as good) log facility rather than syslog (that's the same format I see for TimeMachine log messages extracted from the new log facility; e.g. 2017-01-01 06:18:18.094145-0600 localhost backupd[13915]: (TimeMachine) [com.apple.TimeMachine.TMLogInfo] Backup completed successfully. -- Larry Stone lston...@stonejongleux.com On Tue, 3 Jan 2017, Viktor Dukhovni wrote: On Jan 3, 2017, at 10:33 AM, Robert Chalmers wrote: Do you mean like this ? where ?postfix? shows up.? Jan 3 09:58:20 zeus postfix/smtpd[31070]: connect from unknown[115.71.5.5] Yes. What did you do to get real syslog messages with MacOS/X Sierra? I get output similar to: 2017-01-03 10:11:13.946120-0500 localhost smtpd[7301]: (libpostfix-util.dylib) disconnect from localhost[127.0.0.1] ehlo=1 starttls=0/1 commands=1/2 In which the "postfix/" syslog_name is nowhere in sight. Makes multi-instance logging rather opaque, and breaks the usual way to distinguish submission logging from port 25 logging, ... -- Viktor.
Re: How to restrict encrypted email
> On Jul 16, 2016, at 11:11, Erwan David wrote: > >> Le 16/07/2016 à 19:04, Jan Ceuleers a écrit : >>> On 16/07/16 17:42, Yuval Levy wrote: >>> Imposing the onus on the SMTP server operator is like imposing the onus >>> on gas stations for fueling vehicles used in criminal endeavors. It >>> does not fly because the gas station can't possibly know what the user >>> will use the vehicle for, other than (probably) driving. >> You have ignored the OP's statement that he is a radio amateur, and that >> the FCC prohibits the use of encryption by radio amateurs. This is about >> ensuring that the spectrum that radio amateurs are licensed to use (a >> public resource) is not subverted for private purposes. Hams are >> supposed to be a largely self-policing community; encryption prevents that. >> >> As an individual radio amateur, the OP needs to ensure that he complies >> with the FCC rules if he wants to keep his license. If he cannot >> configure his SMTP server in a compliant manner he should not offer an >> SMTP-based service that transports messages across the ham frequencies. > Wouldn't this mean that data transport on those frequencies is forbidden ? > I agree. Encryption does not imply TLS. A message could be encrypted while still being plain text. For a sufficiently low level definition of encryption, it could even be encrypted while appearing to be unencrypted. For instance, if two people agree that certain words means something different than their commonly accepted meanings, they could communicate in a form that appears to be plain language yet have a different meaning to them than to someone who intercepts it. But the latter example would also apply to voice communications in the amateur bands so since you can't be sure that even voice is unencrypted, I guess they aren't legal either. -- Larry Stone lston...@stonejongleux.com
Re: Adjusting custom transport for comcast.net's throttle
> On May 2, 2016, at 10:40 PM, Noel Jones wrote: > > On 5/2/2016 8:42 PM, Steven Peterson wrote: >> Thank you! This was very helpful. >> >> By setting minimal_backoff_time to 300s globally, postfix now >> attempts to send deferred messages to comcast.net >> <http://comcast.net> every 10 minutes. This is an improvement, but >> it is not obvious why it sends every 10 minutes (600s) and not every >> 5 minutes (300 seconds). Is there another setting that is >> preventing it from repeating every 300 seconds as the >> minimal_backoff_time setting indicates? >> >> Best, Steve >> > > > First, note the minimal backoff is a guaranteed minimum, not a timer > after which an attempt will be tried immediately. Other mail in the > queue or system load may delay the next retry. A badly clogged mail > queue may take hours until it gets around to a retry. > > The queue delay settings are documented here: > http://www.postfix.org/TUNING_README.html#hammer Also in play is the value of queue_run_delay which is "The time between deferred queue scans by the queue manager”. The default is 300s so with minimal_backoff_time also 300s, when a send attempt ends and then 300s (minimal_backoff_time) elapses, the queue run has just occurred and so it waits another almost 300s until the next queue run. If you want it to try every 300s, set minimal_backoff_time to less than queue_run_delay so that the next queue run occurs soon after the backoff_time expires. Note also that the time between runs increases until it reaches maximal_backoff_time. Read the documentation Noel referenced above. -- Larry Stone lston...@stonejongleux.com
Re: Is /usr/bin/mail a link to sendmail/postfix
> On Mar 13, 2016, at 5:07 AM, Jim Reid wrote: > > >> On 13 Mar 2016, at 08:41, Alice Wonder wrote: >> >> It's possible the mail command on OS X is using the OS X sendmail command >> provided by the OS X postfix which would want its configuration file at >> /etc/postfix/main.cf > > It is. Though MacOSX puts the sendmail front-end in /usr/sbin: > % strings /usr/bin/mail | grep / > ... > /usr/sbin/sendmail > ... > >> You may need to move the OS X sendmail command and make a symlink from >> /usr/local/sbin/sendmail (as provided by postfix built from source) to >> /sbin/sendmail (or wherever OS X keeps it) so that the right sendmail >> command is available to OS X mail command. > > Easier said than done. MacOSX 10.11 introduced System Integrity Protection. > This means most, if not all, of the OS cannot be modified by anything unless > the OS is booted in recovery mode and csrutil is used to disable or enable > SIP. [Which probably explains why the Macs now boot twice during an upgrade: > once in recovery mode to make the changes and then another to resume “normal” > operations.] By default the SIP-protected directories and files include > everything in /usr except /usr/local. > > The path of least resistance would be to put the postfix config files in > /etc/postfix where the Apple-supplied postfix tools expect to find them. Be > sure to keep copies of these files elsewhere in case Apple stamps all over > them at the next OS upgrade. Messing around with SIP settings or being clever > with symbolic links is likely to end in pain, particularly when the next > upgrade comes along. I run Postfix (built from source) on one of my Macs and installed into /usr/local. I turned off SIP in order to get my built version of /usr/sbin/sendmail there and have left it off. The only “pain” likely to result is if you aren’t smart and let malware do something bad. OS X (at least so far) does not care if SIP is on or off. SIP, IMHO, is protection for those who don’t know what they are doing but is in the way of us who know our way around a system. While Apple has thrown more barricades in the way of running your own locally built Unix software, they haven’t blocked it yet. Turning off SIP is easy: • Restart your Mac, and as soon as the screen turns black hold down ⌘R until the Apple logo appears on your screen. • Now click on the "Utilities" menu, and then "Terminal". • In the Terminal Window type: • csrutil disable • Restart OS X, your Mac should then restart as normal with SIP disabled, This is a permanent setting so once done would never need to be done again. But if you want to toggle it on and off as needed, to turn it on, just say “csrutil enable” instead. -- Larry Stone lston...@stonejongleux.com smime.p7s Description: S/MIME cryptographic signature
Re: postfix to mailman: User doesn't exist/relay access denied
> Mailman requires local(8) delivery via an aliases(5) file that > belongs to the mailman user. With any luck the OP will post actual > configuration details to this list, rather than some website most > readers won't bother to look at, and someone how knows Postfix<->mailman > integration will provide some help. I expect the poster will get better help on the Mailman Users list (https://mail.python.org/mailman/listinfo/mailman-users/ for information). There are lots of people who use Mailman with Postfix there. In a standard Mailman with Postfix configuration, aliases are created (automatically by Mailman) to pipe the Mailman addresses to the proper Mailman program. Postfix transports are not involved (however, there are a lot of non-standard Mailman distributions out there). It appears the OP is doing something non-standard. -- Larry Stone lston...@stonejongleux.com smime.p7s Description: S/MIME cryptographic signature
Re: socket: malformed response
> On Nov 22, 2015, at 11:13 PM, Peter wrote: > > On 11/23/2015 05:51 PM, Vicki Brown wrote: >> Also, from my discussion with him, Bernard Teo does seem to know what he's >> doing. > > I suggest you type "man postfix", scroll down to the bottom and look at > the list of authors, then compare that list to the two people who have > been trying to help you here. Note that you won't see "Bernard Teo" on > that list. > > You have two people that arguably know more about Postfix than anyone > else in the entire world trying to help you here and you're arguing with > them trying to tell them that they're wrong? I’ll add to that having used Bernard Teo’s product to get my system setup with Postfix initially, I found that like many packages, it sets it up to operate in its own closed universe. When I reached a point where I wanted to integrate other things like Amavis, DKIM signing, and other filters, it was time to move away from what his product set up. -- Larry Stone lston...@stonejongleux.com smime.p7s Description: S/MIME cryptographic signature
Re: socket: malformed response
On Thu, 19 Nov 2015, Wietse Venema wrote: Vicki Brown: cutedge is a company that makes a mail /postfix startup service front end. This was a spurious (coincidental) error, long past resolved and unrelated. /usr/local/cutedge/postfix/etc is actually a symlink to /etc/postfix... This is NOT LONG PAST RESOLVED. You have programs that STILL USE /usr/local/cutedge/postfix/etc as the Postfix configuration directory. Those programs will not work. Vicki, I long ago used Cutedge's product to get me going with Postfix. As far as I know, their product is designed to get Postfix (and Dovecot) set up on a "Client" version of OS X (that is, not OS X Server). Yet IIRC from an earlier post of yours, you're using OS X Server. Considering how (as I understand it) Apple likes to keep the guts of their server products hidden (as well as making non-standard changes to them), I suspect mixing the two is not a good idea. -- Larry Stone lston...@stonejongleux.com
Re: Di I need to open port 25?
On Mon, 15 Jun 2015, L. D. James wrote: You don't need to open port 25. Port 25 is for sending, not receiving mail. Many administrators consider Port 25 a security risk and block it to prevent having their system exploited. You can use port 587 for sending rather than Port 25. Some administrators open port 25 so that their clients can use it for sending email (not receiving). You wouldn't have to do this (have port 25 opened) if you tell the people who have accounts on your server and will be using your server for sending email. This is wrong, wrong, wrong and should be ignored. But first off, terminology. For one system to be sending, another has to be receiving. Port 25 is used by an MTA to receive mail from another MTA. It can also be used by an MTA to receive mail from an MUA (Mail User Agent - a user mail program such as Outlook) although that is not "best practice" these days. 587 (aka the submission port) is the preferred port for an MTA to receive mail from an MUA. Turn off port 25 and you cannot receive mail from another MTA as port 25 is the port MTAs use by default to send to another MTA. Note that these port numbers (25 and 587) are what the receiving server has open for receiving. The sending MTA or MUA sends from a random port. There is no need to define the port being used on the sender (client). Only the port that a server listens on needs to be defined as it needs to be "well-known". But also note that the term "server" when discussing a mail server can be misleading as a mail server also acts as a client when sending to other mail servers. In the mail world (as well as most of the Internet), clients initiate connections from a random port on the client to a "well-known" and defined port on the server. So in short: MTA (acting as client) to another MTA (acting as server) connects from a random port on the client MTA to port 25 on the server MTA. MUA (always acting as clinet) to MTA (acting on server) connects from a random port on the MUA to port 587 (preferred) or port 25 (if permitted) on the server MTA. Use of port 465 was deliberately not included in the above as it does not seem to be part of the OPs issue. -- Larry Stone lston...@stonejongleux.com
Re: How do I compile 3.0.0 on OS X 10.10.3 with SASL support
> On Apr 13, 2015, at 4:16 AM, Robert Chalmers wrote: > > So far I have this. > > make makefiles CCARGS='-DUSE_SASL_AUTH \ > -DDEF_SERVER_SASL_TYPE=\"dovecot\" \ > > CCARGS="-DUSE_TLS -I/usr/local/include" AUXLIBS="-L/opt/local/lib -lssl > -lcrypto” \ > > AUXLIBS="-L/usr/lib -lsasl2” ' > > > Which seems to be ok - however, upon the end of the build, I get this > > lots and lots of these warnings … followed by the error about netinfo. Which > I believe no longer exists in OS X? > > anyway, any advice to get a clean build will be much appreciated > > ./sys_defs.h:1761:1: warning: '/*' within block comment [-Wcomment] > /* Yorktown Heights, NY 10598, USA > ^ > ./sys_defs.h:1762:1: warning: '/*' within block comment [-Wcomment] > /*--*/ > ^ > dict_ni.c:39:10: fatal error: 'netinfo/ni.h' file not found > #include > ^ > 47 warnings and 1 error generated. > make: *** [dict_ni.o] Error 1 > make: *** [update] Error 1 > zeus:postfix-3.0.0 robert$ > Builds fine for me (on my test system - production is still on 10.9.x) with: make -f Makefile.init makefiles \ CCARGS='-DUSE_TLS \ -DUSE_SASL_AUTH \ -DDEF_SERVER_SASL_TYPE=\"dovecot\"\ -DDEF_COMMAND_DIR=\"/usr/local/sbin\"\ -DDEF_CONFIG_DIR=\"/usr/local/etc/postfix\"\ -DDEF_DAEMON_DIR=\"/usr/local/libexec/postfix\"\ -DHAS_PCRE -I/usr/local/include' \ AUXLIBS='-L/usr/local/lib -lpcre -lssl -lcrypto’ -- Larry Stone lston...@stonejongleux.com http://www.stonejongleux.com/ smime.p7s Description: S/MIME cryptographic signature
Re: 5.5.4 Unsupported option:
On Dec 24, 2014, at 1:42 PM, Viktor Dukhovni wrote: > On Wed, Dec 24, 2014 at 10:44:12AM -0800, steve zeng wrote: >> Yes. It is redhat 5 >> >>> who wrote that client and why? >> >> It is a legacy application written years ago by dev team. I will try upgrade >> postfix either on RHEL6 to leverage command_filter as suggested by Mr. >> Venema. The last option would be to get someone to modify the client app >> code. > > That should be the first option, with all others as a potential > stop-gap measure. Don't institutionalize breakage. IMHO, and not specific to Postfix, too many issues come from not following standards and relying on software or tools that silently correct non-standard behavior. Then something is changed and stops the silent correction and doesn’t behave as expected or, as in this case, errors on the non-standard behavior. Do it right and then you won’t have to work around the problem again when the next change is made. -- Larry Stone lston...@stonejongleux.com http://www.stonejongleux.com/ smime.p7s Description: S/MIME cryptographic signature
Re: Postfix stable release 2.11.3 and legacy releases 2.10.5, 2.9.11, and 2.8.19
On Oct 20, 2014, at 10:35 AM, Viktor Dukhovni wrote: > On Mon, Oct 20, 2014 at 10:01:51AM -0500, Larry Stone wrote: > >>> You should no longer need to specify "-lresolv" (though it won't >>> fix this problem), and should never have needed to specify "-arch x86_64?. >> >> Hmmm, that '-arch x86_64' was in a note you (Viktor) posted on 5/11/14 in >> the topic "Client side DANE - minimum openssl version". > > Only because I failed to prune some inessential, but likely harmless > details from the HOWTO in question: > >http://diymacserver.com/mail/snow-leopard/compiling-postfix-in-64-bits/ > > which is still showing wrong usage of "-L/path" to this day. > I’ve moved beyond that site, which seems to no longer keeping up with the OS X changes, in large part thanks to the help you’ve provided. >> with or without the -arch x86_64... > > The target architecture defaults to the machine archicture. You > only need "-arch" when building for a different machine type than > the one you're using. The more you post about these things, the more I learn. So a very sincere "Thank You" for all you contribute to Postfix. -- Larry Stone lston...@stonejongleux.com http://www.stonejongleux.com/ smime.p7s Description: S/MIME cryptographic signature
Re: Postfix stable release 2.11.3 and legacy releases 2.10.5, 2.9.11, and 2.8.19
On Oct 19, 2014, at 11:12 PM, Viktor Dukhovni wrote: > >> $ make -f Makefile.init makefiles \ >>> CCARGS='-arch x86_64 -DUSE_TLS -DUSE_SASL_AUTH \ >>> -DDEF_SERVER_SASL_TYPE=\"dovecot\" \ >>> -DDEF_COMMAND_DIR=\"/usr/local/sbin\" \ >>> -DDEF_CONFIG_DIR=\"/usr/local/etc/postfix\" \ >>> -DDEF_DAEMON_DIR=\"/usr/local/libexec/postfix\" \ >>> -DHAS_PCRE -I/usr/local/include \ >>> -DHAS_MYSQL -I/usr/local/mysql/include' \ >>> AUXLIBS='-L/usr/local/lib -lpcre -lssl -lcrypto -L/usr/local/mysql/lib \ >>> -lmysqlclient -lz -lm -lresolv' > > You should no longer need to specify "-lresolv" (though it won't > fix this problem), and should never have needed to specify "-arch x86_64”. Hmmm, that ‘-arch x86_64’ was in a note you (Viktor) posted on 5/11/14 in the topic "Client side DANE - minimum openssl version". FWIW, running OS X 10.9.5 (latest version of Mavericks), I get a good build of 2.11.3 with make -f Makefile.init makefiles \ CCARGS='-arch x86_64 \ -DUSE_TLS \ -DUSE_SASL_AUTH \ -DDEF_SERVER_SASL_TYPE=\"dovecot\"\ -DDEF_COMMAND_DIR=\"/usr/local/sbin\"\ -DDEF_CONFIG_DIR=\"/usr/local/etc/postfix\"\ -DDEF_DAEMON_DIR=\"/usr/local/libexec/postfix\"\ -DHAS_PCRE -I/usr/local/include' \ AUXLIBS='-L/usr/local/lib -lpcre -lssl -lcrypto’ with or without the -arch x86_64. This is almost the same as what James Brown used except no -lresolv and I don’t use MySQL so all of that is removed. I’ve only done the build (not installed yet) but that is the same command I used for building my currently running 2.11.1. -- Larry Stone lston...@stonejongleux.com http://www.stonejongleux.com/ smime.p7s Description: S/MIME cryptographic signature
Re: how to protect MTAs from mass mails
On Wed, 20 Aug 2014, ml ml wrote: This setup is not very unusual if you have a lager network. Then you have multiple mailout servers for send/deliver the mails. How could i possibly control recipients that do not belong to me?! You failed to adequately describe the problem. We assumed you were talking about inbound mail, not outbound mail. If outbound mail is being abused, you need to deal with whatever user(s) are abusing your server. IMHO, the real problem is you have local users (users sending from an address in mynetworks) who are spamming with fake sender addresses. The backscatter problem is a symptom of the bigger problem of your users abusing your server. Fix the real problem, not the symptom. -- Larry Stone lston...@stonejongleux.com
Re: how to protect MTAs from mass mails
On Aug 20, 2014, at 3:56 AM, ml ml wrote: > rom time to time i get hit by mass mail with fake sender addresses. > > By default my postfix accepted those mails until it found out that the > recipent does not exists. Then postfix tries to send back that "550 > User Unknown" error mail. > > However, the sender is fake. Therefore the mails get stuck on my postfix mta. Why are you accepting mail for non-existent recipients? That is NOT the default Postfix behavior. If the recipient does not exist, by default, Postfix will reject the mail. To get the “accept and then bounce” behavior you seem to have, you have changed something. But since you have provided no information on your configuration, anything further is merely guessing. -- Larry Stone lston...@stonejongleux.com http://www.stonejongleux.com/ smime.p7s Description: S/MIME cryptographic signature
Re: Postfix Squirrelmail Issue
On Aug 14, 2014, at 6:32 PM, hagensieker wrote: > I saw that Larry. I put the code in the raw text tags. Didn't realize it > would email out like that. I'll try again here. > > Not receiving email into squirrel mail or /var/mail/john from outside > network. Locally all is well. > > Between mail programs such as gmail, mac os x mail, and thunderbird mail my > server seems to be working perfectly. Everybody can send and receive from > inside and outside the network, however when I send an email to my linux > user (john) from the outside network it never shows up in /var/mail/john or > on squirrel mail. > > postconf/main.cf > … (major snip page) As stated in the link in the welcome message you received when you joined the list, send postconf -n output (that gives us parameters that have been changed from the defaults), not your main.cf. Logs of a received message are helpful as well. However, as I stated earlier, this is probably not a Postfix issues. -- Larry Stone lston...@stonejongleux.com http://www.stonejongleux.com/ smime.p7s Description: S/MIME cryptographic signature
Re: Postfix Squirrelmail Issue
On Aug 14, 2014, at 4:03 PM, hagensieker wrote: > Not receiving email into squirrel mail or /var/mail/john from outside > network. Locally all is well. > > Between mail programs such as gmail, mac os x mail, and thunderbird mail my > server seems to be working perfectly. Everybody can send and receive from > inside and outside the network, however when I send an email to my linux > user (john) from the outside network it never shows up in /var/mail/john or > on squirrel mail. > > postconf/main.cf > > > > postconf/master.cf > > > > dovecot/conf > > > > dovecot/conf.d/10-main.conf > > > > hostname = hagensieker.org > > /etc/hosts > > > > Can anyone push me in the right direction here? > Well, just giving us the names of your configuration files rather than the contents doesn’t do much for us. But this does not sound like a Postfix problem. Postfix is a Mail Transfer Agent. It is not an IMAP or POP server (that’s what Dovecot does). But if some MUAs (Mail User Agents) are seeing your mail and others aren’t (like Squirrelaail), then I’d guess the ones that aren’t are not configured properly. As for why the mail is not ending up is /var/mail/john, clearly Postfix or whatever Mail Delivery Agent you’re using is not configured to deliver it there. -- Larry Stone lston...@stonejongleux.com http://www.stonejongleux.com/ smime.p7s Description: S/MIME cryptographic signature
Re: Compile errors on Mac "Undefined symbols for architecture x86_64: "_pcre_free_study""
On Jul 16, 2014, at 2:10 AM, Viktor Dukhovni wrote: > On Wed, Jul 16, 2014 at 04:49:49PM +1000, James Brown wrote: > >> So change to: >> >> AUXLIBS=?-L/usr/local/lib -llber -lresolv -L/usr/lib ? ? > > Something like that. Since you're using headers from /usr/local/include, > you need the libpcre from /usr/local/lib. > >>> Is there a libpcre in /usr/lib? >> >> In /usr/lib there is: >> >> -rwxr-xr-x 1 root wheel390528 3 Jul 2011 libpcre.0.dylib >> lrwxr-xr-x 1 root wheel15 3 Jul 2011 libpcre.dylib -> >> libpcre.0.dylib >> -rwxr-xr-x 1 root wheel 34672 3 Jul 2011 libpcreposix.0.dylib >> lrwxr-xr-x 1 root wheel20 3 Jul 2011 libpcreposix.dylib -> >> libpcreposix.0.dylib > > That explains it, I'm on 10.9.4, and there is no libpcre in /usr/lib. > Did you install a previous libpcre into /usr/lib? I doubt that > Apple would remove libpcre from the system if they used to ship > it. That’s odd. I’m on 10.9.4 as well and I DO have libpcre in /usr/lib. $ ls -l /usr/lib/libpcre* -rwxr-xr-x 1 root wheel 403392 Nov 23 2013 /usr/lib/libpcre.0.dylib lrwxr-xr-x 1 root wheel 15 Nov 23 2013 /usr/lib/libpcre.dylib -> libpcre.0.dylib -rwxr-xr-x 1 root wheel 34896 Nov 23 2013 /usr/lib/libpcreposix.0.dylib lrwxr-xr-x 1 root wheel 20 Nov 23 2013 /usr/lib/libpcreposix.dylib -> libpcreposix.0.dylib AFAIK, that came from Apple as anything I install myself goes in /usr/local. It’s also on all three Macs in our household (all have Apple Developer tools installed but only two have my local install of PCRE in /usr/local on them). -- Larry Stone lston...@stonejongleux.com http://www.stonejongleux.com/ smime.p7s Description: S/MIME cryptographic signature
Re: Regarding "reject_authenticated_sender_login_mismatch" domain matching
On Thu, 19 Jun 2014, D'Arcy J.M. Cain wrote: On Thu, 19 Jun 2014 08:17:49 +0300 Vytenis Sabaliauskas wrote: I'm struggling to stop abusing SASL usernames. My idea is to allow any particular SASL username send only from his domain, that is " u...@example.com" can send from "anyth...@example.com", but not from " u...@otherexample.com". I don't know how to do that but I wonder why you want to. The whole point of authentication is to allow your users to get email without having to trust the system they are coming in from. If you trust the domain then just add it to mynetworks and don't bother with authentication. I suggest authentication though so that your users can get their email no matter where they are. People are mobile. Whoa, whoa, whoa. The original poster was asking about sending email. You're talking about getting email which is the role of an IMAP or POP server such as Dovecot, not Postfix. Besides that, mynetworks defines trusted IP addresses, not domains. -- Larry Stone lston...@stonejongleux.com
Re: Client side DANE - minimum openssl version
On May 11, 2014, at 9:04 PM, Viktor Dukhovni wrote: > On Sun, May 11, 2014 at 08:57:29PM -0500, Larry Stone wrote: > >>> The above syntax is incorrect. Try >>> >>> ... CCARGS=' >>> -DUSE_TLS -I/usr/local/ssl/include >>> -DUSE_SASL_AUTH >>> -DDEF_COMMAND_DIR=\"/usr/local/sbin\" >>> -DDEF_CONFIG_DIR=\"/usr/local/etc/postfix\" >>> -DDEF_DAEMON_DIR=\"/usr/local/libexec/postfix\" >>> -DHAS_PCRE -I/usr/local/include >>> ' \ >>> AUXLIBS=' >>> -L /usr/local/ssl/lib -lssl -lcrypto >>> -L/usr/local/lib -lpcre >>> ' >> >> That worked. Thanks. >> >> But I don't understand why. > > Wrong mental model of the C-compiler '-D' option syntax. > >> I'm assuming the key difference was on the -DUSE_TLS directive. > > This is a boolean option, "-DFOO" is equivalent to "-DFOO=1". The > option just activates the '#ifdef USE_TLS #endif' > blocks in the Postfix source code. It DOES NOT take any parameters. > > To include additional directories in the header search path you > need a "-I /some/path" option. > >> With the new OpenSSL version, /usr/local/ssl/include contains >> only the openssl directory which in turn contains all the openssl >> header files. So how does the path specified behind -DUSE_TLS work? > > It is a separate option and need be after or even adjacent to -DUSE_TLS. > Because OpenSSL header files are included as: > > #include > #include > ... > > The right path to add the search path is the directory containing > the "openssl" directory with all the headers. In particular this > works when the header paths are of the form: > > /usr/include/openssl/some_openssl_header.h > > and the default compiler search path contains /usr/include. Viktor, thanks, that greatly improves my understanding of how those options works. And also serves as a reminder not to put to much trust in other people’s “how to” documents since if I now understand it correctly, the '-I/usr/include/openssl’ in the original document I followed at diymacserver.com was meaningless and instead, the headers were found from the default /usr/include. -- Larry Stone lston...@stonejongleux.com http://www.stonejongleux.com/ smime.p7s Description: S/MIME cryptographic signature
Re: Client side DANE - minimum openssl version
On May 11, 2014, at 6:34 PM, Viktor Dukhovni wrote: > On Sun, May 11, 2014 at 06:00:38PM -0500, Larry Stone wrote: > >> On the test system, trying to force the new version of OpenSSL (1.0.1g), I >> used: >> make -f Makefile.init makefiles \ >> CCARGS='-DUSE_TLS /usr/local/ssl/include/openssl \ >> -DUSE_SASL_AUTH \ >> -DDEF_COMMAND_DIR=\"/usr/local/sbin\" \ >> -DDEF_CONFIG_DIR=\"/usr/local/etc/postfix\" \ >> -DDEF_DAEMON_DIR=\"/usr/local/libexec/postfix\" \ >> -DHAS_PCRE -I/usr/local/include' \ >> AUXLIBS='L/usr/local/ssl/lib ?lssl ?lcrypto \ >>-L/usr/local/lib -lpcre -L/usr/lib -lresolv? > > The above syntax is incorrect. Try > > ... CCARGS=' > -DUSE_TLS -I/usr/local/ssl/include > -DUSE_SASL_AUTH > -DDEF_COMMAND_DIR=\"/usr/local/sbin\" > -DDEF_CONFIG_DIR=\"/usr/local/etc/postfix\" > -DDEF_DAEMON_DIR=\"/usr/local/libexec/postfix\" > -DHAS_PCRE -I/usr/local/include > ' \ >AUXLIBS=' > -L /usr/local/ssl/lib -lssl -lcrypto > -L/usr/local/lib -lpcre > ' That worked. Thanks. But I don’t understand why. I’m assuming the key difference was on the -DUSE_TLS directive. With the new OpenSSL version, /usr/local/ssl/include contains only the openssl directory which in turn contains all the openssl header files. So how does the path specified behind -DUSE_TLS work? -- Larry Stone lston...@stonejongleux.com http://www.stonejongleux.com/ smime.p7s Description: S/MIME cryptographic signature
Re: Client side DANE - minimum openssl version
This thread got my intrigued as I have my system (OS X “Client” doing lots of server stuff) almost entirely independent of Apple provided stuff in favor of building from source. OpenSSL is one I have not done. So I decided to try it on my test system (which is really my laptop booted from an alternate disk). On May 9, 2014, at 10:18 AM, Viktor Dukhovni wrote: > On Fri, May 09, 2014 at 10:58:30AM -0400, Wietse Venema wrote: > >>> Any hint's to build postfix + openssl-1.x on a system based on >>> openssl-0.9.x ??? I also avoided building openssl from source for >>> good reasons over the last years. > > It is rather easy to build on Unix-like systems. > > Unpack the tarball, cd to the top-level source directory and run > './config -h'. This will suggest default build options. > > For example, on a Macbook Pro: > >$ ./config -h >Operating system: i686-apple-darwinDarwin Kernel Version 13.1.0: Wed Apr 2 > 23:52:02 PDT 2014; root:xnu-2422.92.1~2/RELEASE_X86_64 >WARNING! If you wish to build 64-bit library, then you have to >invoke './Configure darwin64-x86_64-cc' *manually*. >Configuring for darwin-i386-cc >/opt/local/bin/perl5 ./Configure darwin-i386-cc > >> I have some success with installing OpenSSL in a different location >> (/opt/openssl-1.x.y) and pointing the Postfix CCARGS/AUXLIBS there. > > Then I just run: > >$ ./Configure --prefix=/opt/openssl-1.x.y darwin64-x86_64-cc > I went with './Configure darwin64-x86_64-cc -shared' which puts everything in /usr/local/ssl (the -shared adds the .dylib - maybe I shouldn’t go that route). >> However, this may cause conflicts if you link Postfix with any >> libraries that were compiled against a different OpenSSL version >> (in my case, libldap). > > Indeed DLL-hell is a potential problem. You may also need to build > LDAP, MySQL, PgSQL, ... all linked with the custom version of > OpenSSL. As far as I can tell, the only things I have dependent on OpenSSL are Postfix, Dovecot, and Apache. Apache built fine and mod_info reports OpenSSL 1.0.1g. Dovecot appears to be fine but I haven’t figure out how to tell. But Postfix… First off, I’m a neophyte at make and building C programs. So I don’t fully understand all the options but think I am getting the hang of it. I’ve been building Postfix, adapted from instructions at diymacserver.com, with: make -f Makefile.init makefiles CCARGS='-DUSE_TLS -DUSE_SASL_AUTH \ -DUSE_CYRUS_SASL -I/usr/include/sasl \ -DDEF_COMMAND_DIR=\"/usr/local/sbin\" \ -DDEF_CONFIG_DIR=\"/usr/local/etc/postfix\" \ -DDEF_DAEMON_DIR=\"/usr/local/libexec/postfix\" \ -DHAS_PCRE -I/usr/local/include \ -DHAS_SSL -I/usr/include/openssl' \ AUXLIBS='-L/usr/local/lib -lpcre -lssl -L/usr/lib -llber -lresolv -lsasl2’ Today, after learning a few things and realizing I need neither the LDAP nor Cyrus SASL stuff, I reduced that to: make -f Makefile.init makefiles CCARGS='-DUSE_TLS -I/usr/include/openssl \ -DUSE_SASL_AUTH \ -DDEF_COMMAND_DIR=\"/usr/local/sbin\" \ -DDEF_CONFIG_DIR=\"/usr/local/etc/postfix\" \ -DDEF_DAEMON_DIR=\"/usr/local/libexec/postfix\" \ -DHAS_PCRE -I/usr/local/include' \ AUXLIBS='-L/usr/local/lib -lpcre -lssl -L/usr/lib -lresolv’ which as of earlier today was used to rebuild my production build of 2.11.1. On the test system, trying to force the new version of OpenSSL (1.0.1g), I used: make -f Makefile.init makefiles \ CCARGS='-DUSE_TLS /usr/local/ssl/include/openssl \ -DUSE_SASL_AUTH \ -DDEF_COMMAND_DIR=\"/usr/local/sbin\" \ -DDEF_CONFIG_DIR=\"/usr/local/etc/postfix\" \ -DDEF_DAEMON_DIR=\"/usr/local/libexec/postfix\" \ -DHAS_PCRE -I/usr/local/include' \ AUXLIBS='L/usr/local/ssl/lib –lssl –lcrypto \ -L/usr/local/lib -lpcre -L/usr/lib -lresolv’ It builds fine but when I run it, I get OpenSSL mismatch warnings from both smtp and smtpd: May 11 17:38:14 mbpls.stonejongleux.com postfix/p10028/smtpd[10806]: warning: run-time library vs. compile-time header version mismatch: OpenSSL 1.0.1 may not be compatible with OpenSSL 0.9.8 and May 11 17:38:14 mbpls.stonejongleux.com postfix/smtp[10807]: warning: run-time library vs. compile-time header version mismatch: OpenSSL 1.0.1 may not be compatible with OpenSSL 0.9.8 It all seems to work but obviously pieces of both are getting into the build and as I said, understanding all the nuances of makefiles is beyond me. Also, this is just for curiosity for now so more interested in learning at this point than actually getting it running. But pointing me in the right direction will be appreciated. > > It may be simpler to upgrade your system. AFAIK, Apple does not have a later version of OpenSSL available. -- Larry Stone lston...@stonejongleux.com http://www.stonejongleux.com/ smime.p7s Description: S/MIME cryptographic signature
Re: Getting DKIM to work with Mailman and Postfix
On Mon, 5 May 2014, James B. Byrne wrote: And although I have not the life expectancy to read them all I have found and read many. And I never said that it was a Postfix PROBLEM. I thought that asked if it were not possible to configure Mailman with Postfix so that Mailman's forwarded messages are reprocessed through the milters and signed thereby opendkim rather then sent on directly. On the face of it the question seems reasonable enough. Is there in fact no way to do this? Of course it's possible. But the how is really a Mailman question, not a Postfix question, so your question is probably best asked on the Mailman list. I do it with my Mailman/Postfix server. But merely adding a DKIM signature at your system will not solve the DMARC issue. The list you quoted from DMARC FAQ ealier is not a "do one of these", it's a "do all of these". Mailman 2.1.18 (released just this past weekend) has workarounds for the From and Reply-To piece of this. And despite your claim that you told Mailman to send to port 587 instead (no proof provided), you must not have done what you thought you did. But the Mailman list is the place for what you need. -- Larry Stone lston...@stonejongleux.com
Re: Accept external SMTP traffic only from MX hosts
On Wed, 23 Apr 2014, James B. Byrne wrote: Does the idea of configuring Postfix so that external (to our network) smtp connections are only accepted from servers identified with MX records for the connecting IP address make any sense? Is it possible? No, it makes no sense at all. MX records define what hosts RECEIVE mail for a domain. They say nothing about what hosts should be SENDING mail for a domain. Many large ISPs use separate systems for receiving and sending mail. What you want to do will reject large quantities of legitimate mail. -- Larry Stone lston...@stonejongleux.com
Re: Mails time before queue manager
On Fri, 21 Mar 2014, Viktor Dukhovni wrote: While the OP is not helping by modifying the very information that could be used to solve his problem, the above is taking the admonition way to far. Please apologize and try to stay calm. I'm calm. But I apologize for the apparent tone of my reply. -- Larry Stone lston...@stonejongleux.com
RE: Mails time before queue manager
On Sat, 22 Mar 2014, KK Patnaik wrote: No I didn't add anything. There are lot of logs like that in my server. I am just trying to resolve the delay of the emails. Please advise. Please do not top-post on this mailing list. KK Patnaik: Mar 20 10:43:55 smtp2 postfix/smtp[13548]: 25142124292D: to=, relay=aspmx.l.google.com[74.125.142.26]:25, delay=29217, delays=29775/1441/0.14/1.4, dsn=2.0.0, status=sent (250 2.0.0 OK 1395326635 ac8si2519638icc.108 - gsmtp Mar 20 10:43:55 smtp2 postfix/smtp[13548]: 25142124292D: to=, relay=aspmx.l.google.com[74.125.142.26]:25, delay=2217, delays=775/1441/0.14/1.4, dsn=2.0.0, status=sent (250 2.0.0 OK 1395326635 ac8si2519638icc.108 - gsmtp) You are either deliberately lying or you are in so far over your head that you have no business being anywhere near any computer as an administrator. Do you not see that two log excertps above, both sent by you, are the same except that the delays in the first one have been changed from 2217 to 29217 and from 775 to 29775? The first (which was what you sent originally) is obviously doctored as the delay componenents do not equal the total delay (29775 is greater than 29217 so even before getting to the last three delay components, it's obviously bogus). As Wietse said, you've wasted our time. And if you don't know who Wietse is, I suggest you do a search on his name before posting here again. -- Larry Stone lston...@stonejongleux.com
Re: relay denied in postfix
On Mar 15, 2014, at 9:40 PM, Tim Dunphy wrote: > But it appears that mail IS making its way to the mail server, but being > rejected once it arrives. Did you read the reply I sent earlier? Apparently not. If you’re going to ask for help, you need to actually read the help provided. -- Larry Stone lston...@stonejongleux.com smime.p7s Description: S/MIME cryptographic signature
Re: relay denied in postfix
I see two issues here. You haven’t told it what domains to accept and you’ve
defined mynetworks to be only localhost.
On Mar 15, 2014, at 3:01 PM, Tim Dunphy wrote:
> Hello,
>
>
> I've just built a postfix server in amazon EC2 with an elastic IP. And I
> found that while I can connect to and send emails to my mail server when I
> telnet to localhost when I telnet to the external FQDN I get relay denied.
>
> I'll first demonstrate success, then failure.
>
> And the logs confirm success:
>
> Mar 15 19:27:35 mail postfix/smtpd[5294]: B97CA24B8B:
> client=localhost[127.0.0.1]
> Mar 15 19:28:18 mail postfix/cleanup[5306]: B97CA24B8B:
> message-id=<20140315192735.b97ca24...@mail.example.com>
> Mar 15 19:28:18 mail postfix/qmgr[5221]: B97CA24B8B:
> from=, size=356, nrcpt=1 (queue active)
> Mar 15 19:28:18 mail postfix/cleanup[5306]: AD51725096:
> message-id=<20140315192735.b97ca24...@mail.example.com>
> Mar 15 19:28:18 mail amavis[3401]: (03401-09) Passed BAD-HEADER-1
> {RelayedOutbound,Quarantined}, LOCAL [127.0.0.1]:58766 [127.0.0.1]
> -> , quarantine:
> W/badh-WyjD4kEQ4Mls, Queue-ID: B97CA24B8B, Message-ID:
> <20140315192735.b97ca24...@mail.example.com>, mail_id: WyjD4kEQ4Mls, Hits: -,
> size: 356, queued_as: AD51725096, 140 ms
> Mar 15 19:28:18 mail postfix/smtp[5317]: B97CA24B8B:
> to=, relay=127.0.0.1[127.0.0.1]:10024, delay=51,
> delays=51/0.03/0/0.16, dsn=2.0.0, status=sent (250 2.0.0 from
> MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as AD51725096)
> Mar 15 19:28:18 mail postfix/qmgr[5221]: B97CA24B8B: removed
>
Accepted and queued but no evidence of local delivery. Possibly still queued
until it bounces.
> However, if I telnet to the externally available FQDN (from the mail server)
> I get a relay denied error:
>
> root@mail:~# telnet mail.example.com 25
> Trying xx.xx.xx.xx...
> Connected to mail.example.com.
> Escape character is '^]'.
> 220 mail.example.com ESMTP Postfix (Ubuntu)
> HELO mail.example.com
> 250 mail.example.com
> MAIL FROM:
> 250 2.1.0 Ok
> RCPT TO:
> 454 4.7.1 : Relay access denied
>
Because you’re now connecting from a non-localhost address and you haven’t told
Postfix that’s local.
> Here is the output of postconf -n
>
> mydestination =
>
mydestination defines what domains are to be delivered locally. You set it
blank so you’re saying no domains are delivered locally.
> mynetworks = 127.0.0.0/8 [:::127.0.0.0]/104 [::1]/128
You’ve set this to make only localhost to be considered a local network address.
See http://www.postfix.org/BASIC_CONFIGURATION_README.html for more information.
--
Larry Stone
lston...@stonejongleux.com
http://www.stonejongleux.com/
smime.p7s
Description: S/MIME cryptographic signature
Re: are these 'good and reliable' adls/dynamic pcre rejects?
On Jan 30, 2014, at 10:21 PM, Noel Jones wrote: > On 1/30/2014 7:17 PM, li...@sbt.net.au wrote: >> my pre configured Postfix inluded these helo_access.pcre rejects; >> >> today, I noticed an expected email was bounced by one of the >> pre-configured rules as so: >> >> Jan 31 10:08:01 emu postfix/smtpd[11075]: NOQUEUE: reject: RCPT from >> unknown[59.167.231.218]: 554 5.7.1 : >> Helo command rejected: Go away, bad guy (adsl).; from= >> to= proto=ESMTP >> helo= >> >> host 59.167.231.218 >> 218.231.167.59.in-addr.arpa domain name pointer ns3.cipaname.com. >> >> before I contact the sender to tell them "you are misconfigured"; > > There are some legit static IP servers with a hostname containing > /adsl/, so you'll need to watch out for false positives. How much of > a problem that is will be site specific. I’ll echo what Noel said. And based on your subject, you may have the idea that having (A)DSL service and having a dynamic TCP/IP address are equivalent. They are not! There are a lot of legitimate small business and SOHO servers on static DSL connections (like mine). In many cases, the DSL provider will change the reverse DNS but not always. It’s the dynamic address hostnames you want to block. -- Larry Stone lston...@stonejongleux.com http://www.stonejongleux.com/ smime.p7s Description: S/MIME cryptographic signature
Re: block exe and other attachments
On Sep 16, 2013, at 6:01 AM, Rowland Onobrauche wrote: > > On 16 Sep 2013, at 11:38, Wietse Venema wrote: > >> Rowland Onobrauche: >>> I am currently using mime_header_checks to block certain attachments >>> with such a string - /name=[^>]*\.(scr|pif|bat|exe|dll|vbs)/ REJECT >>> This however does not stop me from receiving 100s of exes and other >>> suspect attachments - which are being blocked by mailscanner, >>> however, i want these blocking at the smtp transaction stage. Can >>> anyone suggest a better way of doing this, so that the checks are >>> successful at smtp transaction? >> >> You made a configuration error. Unfortunately, I am not telepathic. >> >> Wietse > > Not very helpful. > Does anyone else have any advice on this? Per the message you received when you subscribed to this list, TO REPORT A PROBLEM see http://www.postfix.org/DEBUG_README.html#mail We're not mindreaders and if you do not provide the information requested, we can't tell you what you did wrong. -- Larry Stone lston...@stonejongleux.com http://www.stonejongleux.com/ smime.p7s Description: S/MIME cryptographic signature
Re: smtpd optional authentication and relay
On Fri, 5 Jul 2013, W T Riker wrote: Indeed this is using port 587. I did not realize that that in itself was sufficient to prevent relaying from non-authenticated clients. Thanks. It doesn't. If 587 is configured the same as 25, it will behave just like port 25. There is nothing special about port 587 other than how YOU configure it to be different. They key to understanding Postfix restrictions is they evaluate in order and the first to return a result other than DUNNO is what wins. A permit_ restrictions generally returns PERMIT or DUNNO. A reject_ restriction generally returns REJECT or DUNNO. So if you have permit_sasl_authernticated as the first test in a group of restrictions (e.g. smtpd_recipient_restrictions), if the user is SASL authenticated, it returns PERMIT and the mail is accepted and, if not destined locally, relayed. All remaining tests in that group of restrictions are then skipped. If the user is not SASL authenticated, it returns DUNNO and goes on to the next restriction in that group. If that next restriction is reject_unauth_destination (which in case it's not clear to you is the restriction that prevents relaying), an unauthenticated user will not be permitted to relay. So in short, a restriction group that permits authenticated users to send anywhere and unauthenticated users to only send to domains for which Postfix is configure to accept mail would be: permit_sasl_authenticated, reject_unauth_destination. However, don't just do what we suggest; make sure you understand it and that it is doing what YOU want. -- Larry Stone lston...@stonejongleux.com
Re: Investigating iPhone Compatibility
On Jun 17, 2013, at 19:03, Asai wrote: >>> So, it's the iPhone which is self-assertively trying to connect to port 25 >>> regardless of what it's explicitly set to? >> Works fine for me. I very much doubt your iPhone in question is actually set >> to use 587 only. IIRC, that is not the default. >> >> -- Larry Stone >>Sent from my iPhone > OK, so perhaps just refusing AUTH on port 25 will solve the problem. I've > set the Server Port in Outgoing mail settings on iPhone to 587, so I don't > really understand what's going on here... I doubt it. Based on what you previously posted, Postscreen will reject it long before it gets to an smtpd process. I'd suggest you double-check the iPhone configuration. In particular, make sure the outgoing settings you're looking at are the ones actually bring used. You can configure multiple outgoing servers on an iOS device. -- Larry Stone Sent from my iPhone
Re: Investigating iPhone Compatibility
On Jun 17, 2013, at 17:27, Asai wrote: >> On 06/18/2013 12:15 AM, Asai wrote: >>> Would it follow then that I should remove the smtp_sasl_mechanism_filter >>> from main.cf? Would that be causing clients to try to connect via port 25 >>> even though they're set to connect to 587? >> >> ...what makes you think these things are related in any way ? >> >> It is the *client* that decides where to connect to. > So, it's the iPhone which is self-assertively trying to connect to port 25 > regardless of what it's explicitly set to? Works fine for me. I very much doubt your iPhone in question is actually set to use 587 only. IIRC, that is not the default. -- Larry Stone Sent from my iPhone
Re: 2.10 problem
On Jun 4, 2013, at 10:28 PM, Grant wrote: > I tried switching to the following in main.cf: > > smtpd_relay_restrictions = permit_mynetworks,permit_sasl_auth > > but I started getting messages like this in the log: > > warning: unknown smtpd restriction: "permit_sasl_auth" > 451 4.3.5 Server configuration error permit_sasl_auth <> permit_sasl_authenticated -- Larry Stone lston...@stonejongleux.com http://www.stonejongleux.com/ smime.p7s Description: S/MIME cryptographic signature
Re: Is it time for 2.x.y -> x.y?
On May 31, 2013, at 5:48 PM, LuKreme wrote: > I know that some people will see 2.1.1 and think that's exactly the same > thing as 2.10.1, But why should they? As a number, 2.1 and 2.10 are the same thing (except for implied precision). And I can see possible confusion there. But 2.1.0 and 2.10.0 are not valid numbers. Is the 1 and 10 right of the decimal point and the same? Or are they left of the decimal point and different? Uh, both. Or maybe neither. Because 2.1.0 and 2.10.0 aren't numbers. Rather, they're three separate numbers using dots as separators rather than as a decimal point. No doubt no matter what you do, some people will get confused. So stick with what we have which fits with much other software. -- Larry Stone lston...@stonejongleux.com http://www.stonejongleux.com/ smime.p7s Description: S/MIME cryptographic signature
Re: Make install or upgrade for new install location
On Apr 30, 2013, at 7:02 PM, Bill Cole wrote: > Yes, it can. MacPorts creates its own world under /opt/local and uses very > limited parts of of the base system (e.g. the XCode build toolchain) where > necessary. There's no simple way to tell MacPorts that you've installed > dependencies outside of MacPorts that you want it to use instead of its > internal dependencies, but some software (e.g. autoconf scripts and similar > build tools) can sometimes find manually installed stuff in /usr/local and > use it instead of a MacPorts-installed version. Hilarity (or something) > ensues... > > I have found that just using MacPorts where possible instead of maintaining > my own MacOS builds of open source software has been the right choice, > because I really don't get anything out of manually doing the housekeeping > that MacPorts handles for me, and I'm more likely to make a mistake in it > that I will discover because one component breaks when I want it working. Do > I really want to manually keep track of which of the >100 OSS packages I have > installed need rebuilding because I want to fix latest OpenSSL oopsie? No, > not really. If I were starting from scratch, I'd probably go the MacPorts route. But trying to switch a running system is a lot of work. Easier to keep going with what I have. I have a good enough feel for what does what that when something breaks, I usually can deal with it quickly. In fact, on my aborted attempt to upgrade to Mountain Lion (on my "test system" - just my regular MacBook Pro booted off a clone of the server), lots broke. Due to the Postfix issues which I already knew about, I did a MacPorts install of Postfix. But then as I moved on, I found Postfwd wouldn't run as it needed something updated in CPAN. And that's where MacPorts caused me trouble because with the MacPorts changed PATH value, CPAN was updating the MacPorts library, not the one Postfwd was using. >> Just make sure that when you manually build postfix, you don't blindly let >> it link into the base MacOS X world. That can cause trouble (i.e. a need to >> rebuild) after any OS update, major or minor. Apple makes no allowances for >> users replacing base components and will not accommodate your reliance on a >> version of something in /usr/lib/ that they no longer need. I followed the diymacserver.com instructions (mentioned by James Brown in another note although I had already found it) which helped me over a big hurdle which was getting the make makefiles arguments all combined properly. It does dip into /usr/lib for a couple of things - -llber and -lresolv. But the Postfix command, config, and daemon directories are all in /usr/local. The one thing that isn't is sendmail but I have so much (scripts, etc.) that have /usr/sbin/sendmail in them that's it's probably easier to leave that in /usr/sbin, keep a copy, and restore it if Apple wipes it out in an upgrade. Just need to remember to check each time. Anyway, I did a test build and install and all seemed to work as expected with no surprises. But since everything sits behind a NAT router, I have no easy way to route external mail to it. I do have a second IP address I can use so the final test will be to make a good backup, switch the router to the alternate IP address (thereby stopping legitimate outside mail from getting in), install in production, test, and if all seems OK, switch back to the regular IP address. -- Larry Stone lston...@stonejongleux.com http://www.stonejongleux.com/
Re: Make install or upgrade for new install location
On Apr 30, 2013, at 2:27 PM, Reindl Harald wrote: > Am 30.04.2013 21:20, schrieb Larry Stone: >> FWIW, I consider Lion (10.7) to be the last version of OS X for which the >> Apple provided Postfix is usable. For >> Mountain Lion (10.8), they changed a lot of the default directories but also >> removed amavisd-new (compatability >> through OS upgrades apparently is not something Apple thinks has value) > > and that is why nobody seriously uses Apple OSX for production servers > > been there, seen that crap over years > never ever i will use any Apple hardware / software for servers > > long ago they burried their only server hardware X-serve to > give a clear public statement that "Apple Inc." formerly > known as "Apple Compuiters Inc." is no longer interested > in any professional user and has switched to the customer > bullshit market Reindl, I can't say I disagree. But I've been running this server for a good number of years. It supports four users (all family) for email and I run some low volume mailing lists (with Mailman). It uses a Macintosh that would be running here anyway. Buying a "real" Unix system is not going to happen. For the most part, it just runs. If I reach a point I can no longer run it effectively, I outsource the mail and drop the mailing lists. -- Larry Stone lston...@stonejongleux.com http://www.stonejongleux.com/
Re: Make install or upgrade for new install location
On Tue, 30 Apr 2013, Viktor Dukhovni wrote: When it comes time to install, do I do "make install" or "make upgrade"? It's not clear to me if "make upgrade" will work when the upgrade is in a different location than the previous version. You could consider the Postfix from macports. I did consider Macports. Already did some testing with it and it worked fine. But I became comfortable with building from source before I learned about packages so prefer to continue that way when I can. Plus having some stuff from Macports and some from source seems to cause some side issues. FWIW, I consider Lion (10.7) to be the last version of OS X for which the Apple provided Postfix is usable. For Mountain Lion (10.8), they changed a lot of the default directories but also removed amavisd-new (compatability through OS upgrades apparently is not something Apple thinks has value). Plus the pain of Apple provided updates deciding to make changes to main.cf for "security" (Apple considers having something listening 24/7 on port 25 to be a security issue). So now, it's get off the Apple provided Postfix, then amavisd-new, then see about upgrading to Mountain Lion. Otherwise, "make install". Thanks. I had a feeling that was the answer. -- Larry Stone lston...@stonejongleux.com
Make install or upgrade for new install location
I have been running Postfix under Mac OS X for a number of years (now on OS X 10.7.latest (Lion)). I am working on moving away from the Apple provided and customized Postfix to "real" Postfix built from sources. I've successfully built Postfix but not yet tested. To avoid having it overwritten by Apple updates to Postfix, I'm planning to install in /usr/local/ (e.g. /usr/local/etc/postfix, /usr/local/sbin, and /usr/local/libexec/postfix). When it comes time to install, do I do "make install" or "make upgrade"? It's not clear to me if "make upgrade" will work when the upgrade is in a different location than the previous version. -- Larry Stone lston...@stonejongleux.com
Re: New Postfix log analyzer tool, statistics, grapher, ... PostgreSQL DB 9.2.x based
On Apr 13, 2013, at 8:17 AM, /dev/rob0 wrote: > > I think the point is that none of the software you mention are > Linux-specific. Postfix, PostgreSQL, rsyslog, "apache" (Apache > httpd), and php all work and are commonly seen on other Unix and > Unix-like systems. It doesn't sound likely that you have done > something to restrict this to Linux-only. My first thought was he thinks Linux and Unix are just different words for the same thing. Or he knows Linux and has never heard of Unix. Wouldn't be the first. I've run into people (although less technical) who have heard of Linux since it's been a "cool" buzz-word but have no idea what Unix is. -- Larry Stone lston...@stonejongleux.com http://www.stonejongleux.com/
Re: Duplicate Emails Sent RESTATED
On Tue, 19 Mar 2013, Ed wrote: Hi All. I am experiencing an issue with the following: The scenario: From: a...@site1.com To: b...@site2.com CC: m...@site3.com After receiving the email CC at site 3, site 3 is sending out emails to everyone on the original, basically a duplicate email arrives to the sender and everyone in the headers. You then include logs but it's hard to figure out what corresponds to site1, site2, and site3. The logs appear to indicate that there are one or more content filters at play. Noel pointed out what can happen if they're poorly designed. Postfix Site 3 logs and postconf follows Logs -- Mar 14 10:27:41 mail postfix/cleanup[5265]: 10E7BE1C0A:message-id= Mar 14 10:27:41 mail postfix/smtpd[5269]: disconnect from localhost[127.0.0.1] Mar 14 10:27:41 mail postfix/smtp[5266]: 44D90E014D: to=, relay=127.0.0.1[127.0.0.1]:10024, delay=6.5, delays=1.7/0.02/0/4.7, dsn=2.0.0, status=sent (250 2.0.0 Ok, id=03066-15, from MTA([127.0.0.1]:10025): 250 2.0.0 Ok: queued as 10E7BE1C0A) What's this. We see the queue ID reported by the recieving SMTP server in our own logs. Is this just being handed off to our same Postfix instance on another port? Mar 14 10:27:41 mail postfix/qmgr[2179]: 44D90E014D: removed Mar 14 10:27:41 mail postfix/smtp[5270]: 10E7BE1C0A: to=, relay=127.0.0.1[127.0.0.1]:10026, delay=0.05, delays=0.03/0.02/0/0, dsn=2.0.0, status=sent (250 Ok) Handed off to a content filter at port 10026. Mar 14 10:27:41 mail postfix/qmgr[2179]: 10E7BE1C0A: removed Mar 14 10:27:41 mail postfix/smtpd[5272]: connect from localhost[127.0.0.1] Mar 14 10:27:41 mail postfix/smtpd[5272]: 4B9A3E1C0A: client=localhost[127.0.0.1] Mar 14 10:27:41 mail postfix/cleanup[5265]: 4B9A3E1C0A:message-id= Mar 14 10:27:41 mail postfix/qmgr[2179]: 4B9A3E1C0A: from=, size=7049, nrcpt=3 (queue active) And comes back from a content filter with 3 recipients. Seeing your master.cf might help too. But it's most likely the content filter listening to port 10026. -- Larry Stone lston...@stonejongleux.com
Re: Duplicate Emails Sent
On Tue, 19 Mar 2013, Ed wrote: I have control over the site3 SMTP where the problem is. It is recent installation, late last year. Is there a rule in postfix that i missed perhaps? Then please follow the directions you received when you joined the list and include the "postconf -n" output from site3 as well as a log snippet showing the problem. Include both the initial receipt of the message from site1 and the sending of the message back out to the sender and all the recipients. At this point, you should probably also restate your problem since many people do not save every message and would not have your initial statement of the problem. -- Larry Stone lston...@stonejongleux.com
Re: Duplicate Emails Sent
We generally do not top post on this list. Please keep replies in-line. On Mar 19, 2013, at 6:17 AM, Ed wrote: > I have requested the info from site1. > From your initial description, it appears the problem is with site3. Site1 information will probably not be helpful. > I looked for the SMTP RCPT TO command in the man file. > > Could you provide a hint as to the configuration parameter? Sounds like you need to learn about how SMTP works. RCPT TO is one of the commands used between an SMTP client and an SMTP server. The address listed after RCPT TO is what is called the "envelope recipient" and is the destination address to which the server will deliver or forward the mail. The "To" and "CC" headers in a mail message are just part of the message to a mail server (think of it like snail mail - the post office delivers the mail to the recipient on the envelope and does not care at all to whom the letter inside the envelope says it is addressed). Your initial description makes it sound like something at site3 is parsing the message headers (From, To, and CC) and then attempting to resend the message to those addresses. If true, that is very wrong behavior on the part of site3. Your example says "m...@site3.com" so I assume you are the site3 recipient. Are you running some sort of script on the received message that might be doing this? Do you control the site3 SMTP server or are you just a user there? -- Larry Stone lston...@stonejongleux.com http://www.stonejongleux.com/ > > From: Victor d'Agostino > To: postfix-users@postfix.org > Sent: Monday, March 18, 2013 5:45 PM > Subject: Re: Duplicate Emails Sent > > Hi Ed, > > It seems that site3.com smtp server use header recipients instead of SMTP > RCPT TO recipients and also send to the sender ... > > Can you post email headers to check the Received From fields ? > > > Le 18/03/2013 21:51, Ed a écrit : >> Hi All. >> >> The scenario: >> >> From: a...@site1.com >> To: b...@site2.com >> CC: m...@site3.com >> >> After receiving the email CC at site 3, site 3 is sending out emails to >> everyone on the original, >> basically a duplicate email arrives to the sender and everyone in the >> headers. >> >> >>a sends mail to b with me in cc. >> >>me sends mail to everyone in the email headers >> >> I am asking how to stop this behavior.? >> >> I tried in an earlier attempt to post my postconf contents here but was >> rejected due to size. >> >> Thanks >> >> Ed > > >
Re: LDA understanding
On Thu, 14 Mar 2013, Jerry wrote: Personally, I have no idea why anyone uses "procmail". For relatively fine grain sorting of mail upon delivery, I use Dovecot and Sieve. From what I can ascertain, procmail hasn't even been maintained in over a decade. I realize this gets away from Postfix per se but since LDAs are one of the things Postfix has to work with, it's marginally on-topic. I've used Procmail for years. That it hasn't been updated is irrelevant because it just works. Software does not always have to be new to be the right tool. On the other hand, I've only recently delved into Dovecot and then only as an IMAP/POP server. I had been using UW-IMAP, another software package that has not been updated in years but one that unfortunately does not "just work" for all cases (there is some issue between it and iOS Mail). IMHO, Dovecot suffers from being too much and it wasn't until I understood that there are three (maybe more?) distinct parts of Dovecot that operate somewhat independently (IMAP/POP, LDA, and authentication) that I went ahead implemented just the IMAP/POP piece dropping it in place of UW-IMAP with no conversion or client reconfiguration (other than SquirrelMail) required. -- Larry Stone lston...@stonejongleux.com
Re: Postfix being an ass: Relay access denied when rcpt to: is issued
On Mar 12, 2013, at 6:37 PM, Archangel wrote: > Ok, Postfix is acting like a three year old. > When I try to send e-mail in roudcube, it returns, "Relay access denied". I > telnet to port 25 on the server, ehlo and rcpt from without a problem. When > I enter mail to: u...@domain.com it returns 554 5.7.1 : > Relay access denied. Apparently, this is a postfix issue, but idk how to fix > it...even reinstalling postfix from scratch doesn't fix it. Help. > -Aaron Hmmm. You must have missed the part of your list welcome message that said "TO REPORT A PROBLEM see http://www.postfix.org/DEBUG_README.html#mail";. Had you read that, you would found that we need postconf -n output as well as relevant non-verbose logging. It's probably a simple configuration issue. Reinstalling software rather than correcting the configuration is rarely helpful. -- Larry Stone lston...@stonejongleux.com http://www.stonejongleux.com/
Re: Upgrade for Postfix & Mailman
On Fri, 25 Jan 2013, b...@bitrate.net wrote: On Jan 25, 2013, at 15.07, Jeff Bernier wrote: Hello All, I am currently running Mailman (2.1.14) and Postfix (2.4.3) on an aging Mac OS X server (10.5.8). Mailman and Postfix on this system are Apple's implementation on their platform of course. Apple no longer supports the Xserve platform, and I am in need of replacing this system, and upgrading to newer versions of Postfix and Mailman. you may already know this, but do note that while the xserve and mac os x server have gone away, the underlying components themselves [apple and otherwise] have not, and are now just hidden away within "regular" mac os x. apple sells software that you add to your standard install to provide the apple management mechanisms as were found in os x server. of course, this means that an xserve is not needed either, since it runs just fine on any mac. that being said, *do not* misinterpret this information as a suggestion or encouragement that you do this - it is intended only as information, for the sake of it. quite to the contrary, if i were to offer encouragement, it would be to move away from apple products for this sort of thing, but not because the platform has changed. While I have no experience with OS X Server, I have been running a mail server (and related software) on OS X (Client) for several years. Most software for the "server" was installed from sources although I used the Apple provided versions of Postfix and amavisd-new. However, I am currently still running Lion on that machine and from what testing I've done, do not see an easy path forward to Mountain Lion (the current OS X version). In the upgrade to Mountain Lion, a lot of stuff was moved and some things (like amavisd-new) removed. One of the problems of the past was Apple's constant behind the scenes changes which required some reconfiguration at every major upgrade. If I do ever move forward with trying to upgrade, I most likely will go "build from sources" for everything (ignoring Apple's provided Postfix) with everything in /usr/local (which Apple so far does not touch) so that I am not at the whim of their changes. -- Larry Stone lston...@stonejongleux.com
Re: relay access denied
On Wed, 23 Jan 2013, Bernics G?bor | Penta Uni? Zrt. wrote: Please post "postconf -n" in-line, not 600+ lines of full "postconf" to an external site. In-line means in the body of your message, not via pastebin or other websites. postconf -n http://pastebin.com/tHXWZGxC And if you actually compared what's here vs. what you posted in your first message (presumably from main.cf), you'd see that there is no definition of smtpd_recipient_restrictions because you misspelled restrictions. It is because of these kinds of errors that it is asked that you post postconf -n output, not main.cf contents (in other words, the configuration postfix is actually using, not the one you think it is using). -- Larry Stone lston...@stonejongleux.com
Re: postfix-user list features undocumented
On Oct 20, 2012, at 12:43 PM, Mike's unattended mail wrote: > On 2012-10-20, Reindl Harald wrote: >> Am 20.10.2012 14:28, schrieb Mike's unattended mail: >>> How do subscribers turn off the email distribution? >>> How can post acknowledgements be turned on? >> >> Sender: owner-postfix-us...@postfix.org >> Precedence: bulk >> List-Post: <mailto:postfix-users@postfix.org> >> List-Help: <http://www.postfix.org/lists.html> >> List-Unsubscribe: <mailto:majord...@postfix.org> >> List-Subscribe: <mailto:majord...@postfix.org> > > That does not answer the question. Of course, I already checked the > help page. It answers it the way I am interpreting the first question which "how do you unsubscribe?". Perhaps the question you're asking is not clear to us. The language you are using is a bit awkward. What do you mean by "turn off the email distributions" if it doesn't mean "unsubscribe". As for the second question, receiving your own post back does an adequate job of acknowledging the post. Unless, of course, you mean something different when you say "post acknowledgements". -- Larry Stone lston...@stonejongleux.com http://www.stonejongleux.com/
Re: POSTFIX Configuration
On Fri, 17 Aug 2012, Futchko, Rose wrote: I am writing for some help regarding Postfix configuration. I cannot seem to get POSTFIX configured properly to transfer mail to the mailing list installed on the same server. I followed many steps over the last few days, and the last one I followed is at http://www.postfix.org/VIRTUAL_README.html under the section Mailing Lists. From some of the other information you posted, it is clear that you are attempting to use GNU Mailman. I have previously suggested that your question would be better posted to the Mailman-Users mailing list. Information about the list including a subscription sign-up form can be found at <http://mail.python.org/mailman/listinfo/mailman-users/> There are lots of Mailman users there who have it integrated with Postfix so you should be able to get your questions answered there. -- Larry Stone lston...@stonejongleux.com
Re:
On Aug 14, 2012, at 2:49 PM, Futchko, Rose wrote: > Hi, I have one more newbie question. > > I have POSTFIX and MAILMAN on the same server. Mailman is working and can > send out email with no problems. > > Right now the listserv ReplyTO is: x...@mail-test.company.org > > I am not sure how, but would like to change this to: x...@listtest.company.org This is question is best directed to the Mailman users mailing list which you should be able to easily find with a web search. However, before you post to that list, please rephrase your question to eliminate the non-word "listserv". Listserv is a registered trademark for a competing mailing list server and is not a generic term for any mailing list server. -- Larry Stone lston...@stonejongleux.com http://www.stonejongleux.com/
Re: What wrong with my postfix
On Wed, 27 Jun 2012, Kshitij mali wrote: remove my messages I'll try to explain this a little more politely than another poster. This is a mailing list. You send mail to the mailing list, the mailing list software sends it on to the list subscribers, and at that point, the mailing list software on postfix.org (this "site"), is done with it and deletes it. In other words, it was deleted from postfix.org within seconds of you sending it. However, subscribers, which includes some archiving websites independent of postfix.org, are free to do with it as they please. Getting it removed from every place that received it is a near impossibility. I suppose it is possible to request the archiving site to remove them but that's not done by sending an email to this mailing list. Whether they will is an entirely different matter. Meanwhile, I suspect some subscribers maintain their own prvate archives. Think of this as being like you printed a flier and distributed it on a street corner. Once people took some, you really can't go back and tell people to destroy them. You don't know who has them and even if you did, now that they're in their hands, you can't tell them what to do with them. -- Larry Stone lston...@stonejongleux.com
Re: Bcc field not transmitted to applicative layer
On Wed, 20 Jun 2012, Wael MANAI wrote: I read the thread but I don't understand if it's possible to have Bcc parameter in the header of the message. You do understand that the B in BCC means BLIND, right? It wouldn't be very blind if the BCC information were included in the message data. The purpose of BCC is to send a copy to the BCC recipients without there by anything in the message data (note that message headers are part of the message data as far as SMTP is concerned) to indicate that a copy was sent to the BCC recipients. To do otherwise would fundamentally break the definition of BCC. (perhaps part of the problem is younger folk, rarely if ever exposed to traditional office paper communications, are not familiar with why the term is "carbon copy", when "blind carbon copies" were used, and perhaps have never even seen carbon paper) -- Larry Stone lston...@stonejongleux.com
Re: Telnet not authenticating
On May 30, 2012, at 6:14 AM, Masoumeh Izadi wrote: > We have a postfix Email server . when someone telnet to port 25 on our > server, it is possible to send email from any ID user1@anydomain to any > user2@mydomain > When an SMTP client connects to port 25 of your server, it is also possible to send email "from any ID user1@anydomain to any user2@mydomain". What is the problem you are trying to solve? If you have a problem with spam coming in this way, it is just as trivial to do so with some sort of SMTP client. > > The question is that: Is there any solution to prevent this matter or somehow > make postfix to authenticate the users telneting the server directly? No. To an SMTP server such as Postfix, there is no difference between an SMTP client and a Telnet client that is talking to it. SMTP clients essentially use the Telnet protocol to talk to an SMTP server. -- Larry Stone lston...@stonejongleux.com http://www.stonejongleux.com/
Re: Someone is harassing my smtp.
On Apr 23, 2012, at 1:24 AM, Robert Schetterer wrote: > at last what is this? > > reject_unauth_destination' after `check_relay_domains' is ignored I was wondering that myself. A little searching says check_relay_domains was deprecated years ago and replaced with reject_unauth_destination so the OP should probably just remove check_relay_domains from his configuration. -- Larry Stone lston...@stonejongleux.com http://www.stonejongleux.com/
Re: FIXED! Re: Trouble adding sasl support via dovecot
On Mon, 12 Mar 2012, Richard Troy wrote: ...None of the reject_* things seemed to apply, but then, well, CLEARLY at least one of them did... Sure would be nice if the log contained the reason for rejection, however, I'm not complaining; this community has provided me with GREAT software for a LONG time! It did. "Relay access denied" comes from reject_unauth_destination firing. It sounds like you want it to log something like "rejected due to reject_unauth_destination". That's probably dangerous since it would just encourage some people to remove the restriction that was in the way of what they were trying to do. To the extent it makes you actually understand SMTP and Postfix better, it's probably good not to be too specific. -- Larry Stone lston...@stonejongleux.com
Re: Trouble adding sasl support via dovecot
On Mon, 12 Mar 2012, Richard Troy wrote: My problem statement is simply, "it should be working", but doesn't, and I don't get any announcement of "auth" when testing connections to Postfix as per directions here: http://www.postfix.org/SASL_README.html#server_test I haven't seen any followups with the request postconf -n output but: It's not clear if you're trying to do this on port 25 or port 587 (submission). In any event, you have included permit_sasl_authenticated in your smtpd_recipient_restrictions, right? Since if you didn't, that would certainly explain a "relay access denied" reject when attempting to send from outside your network to outside your network. Note that permit_sasl_authenticated must be ahead of reject_unauth_destination. -- Larry Stone lston...@stonejongleux.com
