| Time |
Nick |
Message |
| 06:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:18 |
|
rjackson_isl_hom joined #evergreen |
| 07:30 |
|
collum joined #evergreen |
| 08:06 |
|
Dyrcona joined #evergreen |
| 08:30 |
|
rfrasur joined #evergreen |
| 08:31 |
|
mantis joined #evergreen |
| 08:34 |
|
mmorgan joined #evergreen |
| 09:36 |
|
jvwoolf joined #evergreen |
| 10:54 |
|
alynn26 joined #evergreen |
| 11:20 |
|
mantis joined #evergreen |
| 11:35 |
|
Christineb joined #evergreen |
| 11:46 |
|
rjackson_isl_hom joined #evergreen |
| 11:50 |
|
rjackson_isl_hom joined #evergreen |
| 12:05 |
|
jihpringle joined #evergreen |
| 12:40 |
|
Dyrcona joined #evergreen |
| 12:52 |
|
collum joined #evergreen |
| 13:05 |
|
collum joined #evergreen |
| 13:45 |
|
khuckins joined #evergreen |
| 14:55 |
|
mantis1 joined #evergreen |
| 15:02 |
|
Guest8759 joined #evergreen |
| 15:14 |
Dyrcona |
Oh, right... AG is Antigua and Barbuda, not Argentina (which is AR). en_AG makes a lot more sense, now. ;) |
| 15:46 |
Bmagic |
Has anyone wrestled with getting the "Return-PATH" header changed on an Evergreen utility server? The mail server on the other end requires that the Return-PATH be the authority (rather than FROM) for spam purposes |
| 15:46 |
Bmagic |
I've edited sendmail.mc (and compiled it, etc) basd on this suggestion: |
| 15:46 |
Bmagic |
https://serverfault.com/questions/481971/is-it-possible-to-change-return-path-in-sendmail |
| 15:49 |
Dyrcona |
Bmagic: Are you using sendmail for email? The default on Debian and Ubuntu is to use exim4. |
| 15:49 |
Bmagic |
sendmail |
| 15:52 |
Dyrcona |
My advice: Switch to either postfix or exim4, in that order. (NB: I use exim4, but I'm recommending postfix.) |
| 15:52 |
Bmagic |
well, bummer. It means I have to overhaul lots more than I want to |
| 15:53 |
jeff |
you re-ran the m4 commands to generate your new sendmail.cf after making changes to sendmail.mc, and you restarted sendmail? |
| 15:53 |
jeff |
can you share your sendmail.mc and/or sendmail.cf? |
| 15:53 |
Dyrcona |
You should be able to get what you want working, but from reading that stackoverflow it sounds like sendmail needed to be compiled with a specific option set, and then you need to set the M4 macros correctly, and then generate the config. |
| 15:54 |
Bmagic |
jeff: cd /etc/mail && /usr/sbin/makemap hash authinfo < authinfo |
| 15:54 |
Bmagic |
followed by /usr/bin/make -C /etc/mail |
| 15:54 |
jeff |
And can you expand a bit on what tool/tech/product is the motivation behind this? |
| 15:54 |
Bmagic |
and finally: /etc/init.d/sendmail restart |
| 15:54 |
Dyrcona |
postfix and exim4 are much easier to configure. |
| 15:55 |
Dyrcona |
Is that really how you do it? It has been years since I used sendmail, but I seem to recall the commands being different. Granted, it may not even have been on Linux when I last used sendmail. |
| 15:56 |
jeff |
CentOS does appear to use a Makefile to support "make -C /etc/mail" rebuilding the sendmail.cf from the sendmail.mc source config file |
| 15:56 |
Bmagic |
that's what I've been using to configure sendmail since "the beginning" (of my brain) |
| 15:57 |
Dyrcona |
OK. |
| 15:59 |
Bmagic |
At first I figured we could set the Return-PATH value in the header with the Evergreen AT template. That didn't work. Apparently it's getting clobbered by sendmail. |
| 16:01 |
Bmagic |
It's not clear what mail server the client is using. The mail from the Evergreen server is landing in spam despite the SPF records being correct and the rest of the headers being correct. They are blaming Return-PATH. Which admittedly is getting set to "postmaster mobiusconsortium.org" no matter what I do |
| 16:02 |
Dyrcona |
So? Sounds like it is the recipient's problem, not yours. |
| 16:03 |
Dyrcona |
I'm assuming they've messed up their end. |
| 16:03 |
Bmagic |
I tend to agree, but, it does seem like a knob I should be able to twist |
| 16:03 |
Dyrcona |
It's also called the envelop sender. That might help you with your Googling. |
| 16:04 |
jeff |
What does your mail path look like? |
| 16:04 |
Dyrcona |
Do you have different email domains in your From headers? |
| 16:04 |
jeff |
Generally, you should not be setting Return-Path to anything. It's intended to be set by the software performing the final delivery. |
| 16:05 |
Bmagic |
we relay through Google's SMTP relay (utility server is on GCP) |
| 16:05 |
Bmagic |
perhaps they are doing it |
| 16:06 |
Bmagic |
jeff++ # thinking more along those lines, I think you're right. GCP is setting that |
| 16:06 |
jeff |
so, you have a GCP instance sending email through a Google Workspace account? |
| 16:06 |
Bmagic |
yes |
| 16:08 |
Dyrcona |
You're not using Googel as a smarthost? (Just asking for clarity.) |
| 16:08 |
Bmagic |
I don't think so? |
| 16:09 |
jeff |
Google Workspace SMTP relay will rewrite the envelope from if the domain in the envelope from is not one of the domains on your Google Workspace account: |
| 16:09 |
jeff |
> If the envelope sender is not in one of your domains, the system changes the envelope sender from user@[domain you don't own] to postmaster@[your domain], where [your domain] is the domain the system receives from SMTP AUTH or from the HELO or EHLO command. |
| 16:09 |
jeff |
see https://support.google.com/a/answer/2956491 |
| 16:09 |
Bmagic |
yep, there it is |
| 16:09 |
Bmagic |
jeff++ |
| 16:11 |
jeff |
one option would be to ensure that your envelope from is set to something that uses a domain that's active on your Google Workspace account. that might involve setting up multiple new subdomains like notices.[library's actual domain name here] |
| 16:12 |
Dyrcona |
Another option is to totally change your email infrastructure. |
| 16:12 |
jeff |
another option would be to use a different SMTP relay provider, either free or paid plan. GCP docs list three of the more well-known options: https://cloud.google.com/compute/docs/tutorials/sending-mail |
| 16:12 |
Dyrcona |
:) |
| 16:12 |
Dyrcona |
Or, you could do nothing and know that some recipients won't get their notices. |
| 16:13 |
Dyrcona |
I love email problems always become the sender's problem when 9 times out of 10 the recipient server is the one that's broken. :) |
| 16:13 |
jeff |
you could also spin up a small instance somewhere like Linode or wherever else you have that's semi-conducive to sending email. Just keep in mind that you may want/need to warm that IP before you start sending hundreds of emails from it. |
| 16:14 |
Bmagic |
thanks guys! My first stop is to try and get them to change their server config and "relax" a bit on the domain+IP+TXT a bit. But, all good suggestions, and I will continue to pursue it |
| 16:14 |
Dyrcona |
Hundreds? I think you mean thousands. We send 15,000+ emails on a slow day. |
| 16:14 |
jeff |
email has all kinds of fun intracacies. |
| 16:15 |
Bmagic |
no doubt |
| 16:15 |
Dyrcona |
SMTP itself is rather simple. It's the mess that has built up around it that is the problem. |
| 16:15 |
jeff |
Dyrcona: I wasn't making assertions of normal mail volume (though it's probably under 10,000/day if Bmagic is using Google Workspace SMTP relay services), just a recommendation of not sending a lot of mail through a new host from a cold start. :-) |
| 16:15 |
Dyrcona |
Everyone wants a system where anyone in the world can send them a message at any time, and then they get mad when they do. :) |
| 16:16 |
Dyrcona |
jeff: True. Good way to get yourself blacklisted. |
| 16:17 |
Bmagic |
:) |
| 16:20 |
jeff |
keep in mind that you can add those alternate domains to your existing Google Workspace account as secondary domains. You don't need a separate Google Workspace account for each domain. |
| 16:20 |
jeff |
(up to about 600 domains) |
| 16:21 |
Bmagic |
I'm aware, but in this case, I don't think the library wants to give us that kind of control :) |
| 16:22 |
jeff |
it would be for a subdomain that you dedicate to your use when sending mail on their behalf, but yes... there's a bit of coordination and setup involved, especially if you don't control their DNS. |
| 16:22 |
Bmagic |
that's an option I floated a few weeks ago. We may revisit |
| 16:22 |
Dyrcona |
We had all kinds of fun at MVLC with SPF. Our record was in danger of becoming too large at one point. |
| 16:23 |
jeff |
Still leaning toward the receiving end being at fault, but I don't have the full context. :-) |
| 16:23 |
Bmagic |
Dyrcona: Yep, we had the same issue many times. Because the Google SMTP relay could come from any random Google-owned IP, you have to put a block of IP's into the SPF record. Sometimes resolves to 12+ IPs |
| 16:24 |
Dyrcona |
There's some limit on number of DNS lookups before the receiver is allowed to give up and say, "No." |
| 16:25 |
Dyrcona |
Well, the receiving end *should* be able to make exceptions, but I don't know anything about their setup. |
| 16:25 |
jeff |
>10 = fail |
| 16:25 |
jeff |
keep in mind that you can include: an SPF record, like _spf.google.com |
| 16:25 |
Bmagic |
jeff: that's what we recommend |
| 16:26 |
Bmagic |
Dyrcona: right, I've learned that limitation over the years |
| 16:26 |
Dyrcona |
Right. It's the number of included records. You can list a whole bunch of IPs in 1 record. |
| 16:29 |
|
jvwoolf left #evergreen |
| 17:07 |
|
mmorgan left #evergreen |
| 18:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
