The following changes since commit 37624b58542fb9f2d9a70e6ea006ef8a5f66c30b:
Linux 5.1-rc7 (2019-04-28 17:04:13 -0700)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git tags/spi-v5.2
for you to fetch changes up to 2e5f081003f033d37be3faf052aaccc8b6a44aa5:
Merge branch 'spi-5.2' into spi-next (2019-05-02 11:20:29 +0900)
----------------------------------------------------------------
spi: Updates for v5.2
One small feature was added this release but the bulk of the diffstat
and the changelog comes from the fact that several older drivers got
some fairly hefty reworks and a couple of new drivers were added:
- Support for detailed control of timing around chip selects from
Sowjanya Komatineni.
- A big set of fixes and imrovements for the Tegra114 driver from
Sowjanya Komatineni.
- A big simplification of the GPIO driver from Andrey Smirnov.
- DMA support and fixes for the Freescale LPSPI driver from Clark Wang.
- Fixes and optimizations for the bcm2835aux from Martin Sparl.
- New drivers for Mediatek MT7621 (graduated from staging) and Zynq QSPI.
----------------------------------------------------------------
Aditya Pakki (1):
spi : spi-topcliff-pch: Fix to handle empty DMA buffers
Andrey Smirnov (12):
spi: gpio: Drop unused spi_to_pdata()
spi: gpio: Add local struct device pointer in spi_gpio_probe()
spi: gpio: Add local struct spi_bitbang pointer in spi_gpio_probe()
spi: gpio: Simplify SPI_MASTER_NO_TX check in spi_gpio_probe()
spi: gpio: Drop unused pdata copy in struct spi_gpio
spi: gpio: Don't request CS GPIO in DT use-case
spi: Don't call spi_get_gpio_descs() before device name is set
spi: gpio: Drop mflags argument from spi_gpio_request()
spi: gpio: Drop unused pdev field in struct spi_gpio
spi: gpio: Make sure spi_master_put() is called in every error path
spi: bitbang: Introduce spi_bitbang_init()
spi: gpio: Use devm_spi_register_master()
Andy Shevchenko (3):
spi: pxa2xx-pci: Drop unused header inclusion
spi: pxa2xx: Introduce DMA burst size support
spi: pxa2xx: Debug print DMA burst size
Arnd Bergmann (3):
spi: work around clang bug in SPI_BPW_RANGE_MASK()
spi: fix SPI_BPW_RANGE_MASK() regression
spi: export tracepoint symbols to modules
Axel Lin (4):
spi: at91-usart: Remove duplicated checking for spi->bits_per_word
spi: fsl-lpspi: Fix problematic dev_set_drvdata call
spi: fsl-lpspi: Fix build warning when !CONFIG_PM
spi: fsl-lpspi: Clean up fsl_lpspi_probe
Cao Van Dong (1):
spi: sh-msiof: Document r8a77470 bindings
Cezary Gapinski (1):
spi: pic32: fix dma channels termination
Chris Lesiak (1):
spi: Fix zero length xfer bug
Clark Wang (9):
spi: lpspi: Add i.MX8 boards support for lpspi
doc: lpspi: Document DT bindings for LPSPI clocks
spi: lpspi: add the error info of transfer speed setting
spi: lpspi: use the core way to implement cs-gpio function
spi: lpspi: add dma mode support
spi: lpspi: Add the missing NULL check
spi: lpspi: Code cleanup
spi: lpspi: fix dataloss when SS is inactivated between every words
spi: lpspi: add missing complete in abort func at dma mode
Claudiu Beznea (1):
spi: atmel-quadspi: fix crash while suspending
Daniel Gomez (1):
spi: AD ASoC: declare missing of table
Evan Green (1):
spi: pxa2xx: Add support for Intel Comet Lake
Fabien Dessenne (2):
spi: stm32-qspi: manage the get_irq error case
spi: stm32: return the get_irq error
Flavio Suligoi (3):
spi: pxa2xxx: change "no DMA channels..." msg from debug to warning
spi: pxa2xx: use a module softdep for dw_dmac
spi: pxa2xx: fix SCR (divisor) calculation
Gareth Williams (1):
dt-bindings: snps,dw-apb-ssi: Add optional clock bindings documentation
Geert Uytterhoeven (8):
spi: rspi: Fix register initialization while runtime-suspended
spi: rspi: Fix sequencer reset during initialization
spi: sh-msiof: Use BIT() and GENMASK()
spi: sh-msiof: Use readl_poll_timeout_atomic() instead of open-coding
spi: sh-msiof: Add reset of registers before starting transfer
spi: spi-gpio: Remove spi->controller_data comment
spi: Add missing error handling for CS GPIOs
spi: sh-msiof: Convert to use GPIO descriptors
Han Xu (1):
spi: lpspi: enable runtime pm for lpspi
Hoan Nguyen An (1):
spi: rspi: Fix handling of QSPI code when transmit and receive
Jan Kundr?t (2):
spi: spidev: Enable control of inter-word delays
spi: orion: Support spi_xfer->word_delay_usecs
Jarkko Nikula (3):
spi: pxa2xx: Use struct spi_device directly in pxa2xx_spi_transfer_one()
spi: pxa2xx: Unify remaing prints in pxa2xx_spi_transfer_one()
spi: Remove one needless transfer speed fall back case
Leilk Liu (1):
dt-bindings: spi: spi-mt65xx: add support for MT8516
Linus Walleij (1):
spi: ep93xx: Convert to use CS GPIO descriptors
Ludovic Barre (4):
spi: spi-mem: stm32-qspi: avoid memory corruption at low frequency
spi: spi-mem: stm32-qspi: add suspend/resume support
spi: stm32-qspi: add spi_master_put in release function
spi: stm32-qspi: add dma support
Mark Brown (5):
Merge branch 'spi-5.1' into spi-5.2 for stm32
Merge tag 'v5.1-rc1' into spi-5.2
Merge branch 'spi-5.1' into spi-5.2
Merge branch 'spi-5.1' into spi-linus
Merge branch 'spi-5.2' into spi-next
Martin Sperl (9):
spi: bcm2835aux: unifying code between polling and interrupt driven code
spi: bcm2835aux: remove dangerous uncontrolled read of fifo
spi: bcm2835aux: fix corruptions for longer spi transfers
spi: bcm2835aux: remove dead code
spi: bcm2835aux: fix driver to not allow 65535 (=-1) cs-gpios
spi: bcm2835aux: warn in dmesg that native cs is not really supported
spi: bcm2835aux: setup gpio-cs to output and correct level during setup
spi: bcm2835aux: make the polling duration limits configurable
spi: bcm2835aux: add driver stats to debugfs
Meghana Madhyastha (1):
spi/spi-bcm2835: Split transfers that exceed DLEN
Naga Sureshkumar Relli (4):
spi: spi-mem: export spi_mem_default_supports_op()
dt-bindings: spi: Add device tree binding documentation for Zynq QSPI controller
spi: spi-mem: Add support for Zynq QSPI controller
spi: spi-mem: zynq-qspi: Fix build error on architectures missing readsl/writesl
Noralf Tr?nnes (3):
spi: Remove warning in spi_split_transfers_maxsize()
spi: Release spi_res after finalizing message
spi/trace: Cap buffer contents at 64 bytes
Phil Edworthy (2):
dt-bindings: snps,dw-apb-ssi: Add mandatory clock bindings documentation
spi: dw: Add support for an optional interface clock
Randolph Maa?en (1):
spi: tegra20-slink: change chip select action order
Rasmus Villemoes (5):
spi: spi-fsl-spi: support use of the SPISEL_BOOT signal on MPC8309
spi: spi-fsl-spi: remove always-true conditional in fsl_spi_do_one_msg
spi: spi-fsl-spi: relax message sanity checking a little
spi: spi-fsl-spi: allow changing bits_per_word while CS is still active
spi: spi-fsl-spi: automatically adapt bits-per-word in cpu mode
Serge Semin (1):
spi: Clear SPI_CS_HIGH flag from bad_bits for GPIO chip-select
Sergei Shtylyov (2):
spi: kill useless initializer in spi_register_controller()
spi-mem: fix kernel-doc for spi_mem_dirmap_{read|write}()
Sowjanya Komatineni (22):
spi: tegra114: clear packed bit for unpacked mode
spi: tegra114: fix for unpacked mode transfers
spi: tegra114: terminate dma and reset on transfer timeout
spi: tegra114: flush fifos
spi: tegra114: configure dma burst size to fifo trig level
spi: tegra114: reset controller on probe
spi: tegra114: use packed mode for 32 bits per word
spi: tegra114: add SPI_LSB_FIRST support
spi: tegra114: de-assert CS before SPI mode change
spi: tegra114: avoid reset call in atomic context
spi: tegra114: dump SPI registers during timeout
spi: tegra114: set supported bits per word
spi: tegra114: use unpacked mode for below 4 bytes
spi: tegra114: set bus number based on id
spi: tegra114: add dual mode support
spi: tegra114: add 3 wire transfer mode support
spi: tegra114: add support for interrupt mask
spi-summary: document set_cs_timing
spi: add a method for configuring CS timing
spi: document tx/rx clock delay properties
spi: expand mode support
spi: tegra114: fix PIO transfer
Stefan Roese (1):
spi: mt7621: Move SPI driver out of staging
Trent Piepho (2):
spi: imx: add module parameter to control DMA use
spi: imx: stop buffer overflow in RX FIFO flush
Volker Haspel (1):
spi: spi-fsl-qspi: use devm_spi_register_controller
Wolfram Sang (1):
spi: mxic: simplify getting .driver_data
YueHaibing (4):
spi: atmel-quadspi: Make atmel_qspi_get_name static
spi: bcm2835aux: Fix build error without CONFIG_DEBUG_FS
spi: spi-mem: Fix build error without CONFIG_SPI_MEM
spi: spi-mem: Make spi_mem_default_supports_op() static inline
kbuild test robot (3):
spi: lpspi: fsl_lpspi_runtime_resume() can be static
spi: spi-mem: stm32-qspi: stm32_qspi_pm_ops can be static
spi: bcm2835aux: polling_limit_us can be static
Documentation/devicetree/bindings/spi/fsl-spi.txt | 4 +
.../bindings/spi/nvidia,tegra114-spi.txt | 20 +
Documentation/devicetree/bindings/spi/sh-msiof.txt | 1 +
.../devicetree/bindings/spi/snps,dw-apb-ssi.txt | 10 +-
.../devicetree/bindings/spi/spi-fsl-lpspi.txt | 10 +-
.../devicetree/bindings/spi/spi-mt65xx.txt | 1 +
.../devicetree/bindings/spi/spi-mt7621.txt | 26 +
.../devicetree/bindings/spi/spi-zynq-qspi.txt | 25 +
Documentation/spi/spi-summary | 6 +
arch/arm/mach-ep93xx/edb93xx.c | 13 +-
arch/arm/mach-ep93xx/simone.c | 11 +-
arch/arm/mach-ep93xx/ts72xx.c | 25 +-
arch/arm/mach-ep93xx/vision_ep9307.c | 15 +-
arch/sh/boards/mach-ecovec24/setup.c | 12 +-
drivers/spi/Kconfig | 16 +-
drivers/spi/Makefile | 2 +
drivers/spi/atmel-quadspi.c | 8 +-
drivers/spi/spi-at91-usart.c | 8 +-
drivers/spi/spi-bcm2835.c | 39 +-
drivers/spi/spi-bcm2835aux.c | 205 ++++--
drivers/spi/spi-bitbang.c | 66 +-
drivers/spi/spi-dw-mmio.c | 12 +
drivers/spi/spi-ep93xx.c | 32 +-
drivers/spi/spi-fsl-lib.h | 2 +
drivers/spi/spi-fsl-lpspi.c | 573 ++++++++++++++--
drivers/spi/spi-fsl-qspi.c | 2 +-
drivers/spi/spi-fsl-spi.c | 81 ++-
drivers/spi/spi-gpio.c | 227 +++---
drivers/spi/spi-imx.c | 9 +-
drivers/spi/spi-mem.c | 8 +-
drivers/{staging/mt7621-spi => spi}/spi-mt7621.c | 83 ++-
drivers/spi/spi-mxic.c | 6 +-
drivers/spi/spi-orion.c | 4 +
drivers/spi/spi-pic32.c | 2 +-
drivers/spi/spi-pxa2xx-dma.c | 4 +-
drivers/spi/spi-pxa2xx-pci.c | 5 +-
drivers/spi/spi-pxa2xx.c | 38 +-
drivers/spi/spi-rspi.c | 119 ++--
drivers/spi/spi-sh-msiof.c | 224 +++---
drivers/spi/spi-stm32-qspi.c | 229 ++++++-
drivers/spi/spi-stm32.c | 5 +-
drivers/spi/spi-tegra114.c | 310 +++++++--
drivers/spi/spi-tegra20-slink.c | 12 +-
drivers/spi/spi-topcliff-pch.c | 15 +-
drivers/spi/spi-zynq-qspi.c | 761 +++++++++++++++++++++
drivers/spi/spi.c | 76 +-
drivers/spi/spidev.c | 4 +-
drivers/staging/Kconfig | 2 -
drivers/staging/Makefile | 1 -
drivers/staging/mt7621-spi/Kconfig | 6 -
drivers/staging/mt7621-spi/Makefile | 1 -
drivers/staging/mt7621-spi/TODO | 5 -
include/linux/platform_data/spi-ep93xx.h | 4 -
include/linux/spi/pxa2xx_spi.h | 1 +
include/linux/spi/spi-mem.h | 12 +
include/linux/spi/spi.h | 24 +-
include/linux/spi/spi_bitbang.h | 1 +
include/trace/events/spi.h | 10 +-
include/uapi/linux/spi/spidev.h | 6 +-
sound/soc/codecs/adau1977-spi.c | 11 +
60 files changed, 2650 insertions(+), 800 deletions(-)
create mode 100644 Documentation/devicetree/bindings/spi/spi-mt7621.txt
create mode 100644 Documentation/devicetree/bindings/spi/spi-zynq-qspi.txt
rename drivers/{staging/mt7621-spi => spi}/spi-mt7621.c (88%)
create mode 100644 drivers/spi/spi-zynq-qspi.c
delete mode 100644 drivers/staging/mt7621-spi/Kconfig
delete mode 100644 drivers/staging/mt7621-spi/Makefile
delete mode 100644 drivers/staging/mt7621-spi/TODO
Mark,
gmail once again hates your emails. Your email ends up as spam, due to
dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org
but it has a DKIM signature for sirena.org.uk:
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
d=sirena.org.uk; ...
Hmm?
Linus
On Mon, May 06, 2019 at 12:01:44PM -0700, Linus Torvalds wrote:
> Mark,
> gmail once again hates your emails. Your email ends up as spam, due to
>
> dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org
That looks like it's a fail on validation of the kernel.org bit of
things which I have no control over and which purposely doesn't
advertise DKIM stuff in the hope that people will actually be able to
send mail from non-kernel.org mail servers. I'm really unsure why
that's failing at all, there's no policy for kernel.org to fail.
> but it has a DKIM signature for sirena.org.uk:
>
> DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
> d=sirena.org.uk; ...
which should match the envelope sender.
As far as I can tell Google is going to be unhappy no matter what unless
I use their services - if there's DKIM records it's not going to like
that the from is from kernel.org and if I don't have DKIM records then
it's not going to like that either and I'll be more vulnerable to the
blacklists that try to extort money out of people for permanent
delisting.
Possibly it's not actually anything to do with the DKIM and it's just
upset that I'm travelling and so the mail was injected from a mobile
broadband IP in Japan which doesn't match up with the .uk domain.
On Mon, May 6, 2019 at 7:19 PM Mark Brown <[email protected]> wrote:
> >
> > dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org
>
> That looks like it's a fail on validation of the kernel.org bit of
> things which I have no control over and which purposely doesn't
> advertise DKIM stuff in the hope that people will actually be able to
> send mail from non-kernel.org mail servers.
Looking around, I think you're right, and it's probably not actually
the DKIM thing that causes problems.
Because yes, kernel.org dmarc will just say "ignore".
So I think it's just google that still doesn't like sirena.org.uk.
Iirc, that's happened before, no?
Linus
On Tue, May 07, 2019 at 11:18:53AM +0900, Mark Brown wrote:
> Possibly it's not actually anything to do with the DKIM and it's just
> upset that I'm travelling and so the mail was injected from a mobile
> broadband IP in Japan which doesn't match up with the .uk domain.
I've tried sending equivalent mail to one of my own Google accounts and
it gets delivered, though I do see the dmarc=fail bit in the headers.
The full header there is for a newer spec called ARC that builds even
more stuff on top of DKIM and SPF.
ARC-Authentication-Results: i=1; mx.google.com;
dkim=pass [email protected] header.s=20170815-heliosphere header.b=gYHUGKmm;
spf=pass (google.com: best guess record for domain of [email protected] designates 2a01:7e01::f03c:91ff:fed4:a3b6 as permitted sender) [email protected];
dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org
which suggests it's adding some guesswork in there on top of what's
explicitly in there for SPF (though that's not causing trouble as it
worked out that the mail is OK). The fact that this got through OK and
all the NONEs there suggest that they are to at least some extent doing
the right thing with the lack of any advertised policies for kernel.org,
either something else about the message or your incoming mail is causing
the spam filtering.
Unfortunately I can't immediately see any exim stuff for ARC (and I
don't know that there's anything there that could really help) and I
can't do DKIM for kernel.org (for good reasons), the only thing I can
think of is to disable signing of the From: and hope Google just stop
trying to validate it but that doesn't seem ideal. Everything I'm
seeing is saying that Google just isn't enthusiastic about domains like
kernel.org which is going an issue.
Not really sure what I can do here...
On Mon, May 06, 2019 at 07:34:29PM -0700, Linus Torvalds wrote:
> So I think it's just google that still doesn't like sirena.org.uk.
> Iirc, that's happened before, no?
In the past that always looked like it was triggered by some of the
blacklists that basically seem to have a business model that involves
at least partly charging people money for whitelisting and so are
perhaps a little trigger happy when it comes to listing servers. This
time around I'm not seeing any signs of that happening but I might've
missed some, I don't know if Google stopped using those blacklists or
something.
On Mon, May 6, 2019 at 8:02 PM Mark Brown <[email protected]> wrote:
>
> Everything I'm
> seeing is saying that Google just isn't enthusiastic about domains like
> kernel.org which is going an issue.
Well, there are other people who use kernel.org email addresses. Ingo
Molnar, Rafael Wysocki, a couple of others. But you're the one
getting marked as spam.
Somebody just hates you. I do end up checking my spam-box regularly,
so maybe it doesn't matter.
Linus
On Mon, May 06, 2019 at 08:13:49PM -0700, Linus Torvalds wrote:
> On Mon, May 6, 2019 at 8:02 PM Mark Brown <[email protected]> wrote:
> > Everything I'm
> > seeing is saying that Google just isn't enthusiastic about domains like
> > kernel.org which is going an issue.
> Well, there are other people who use kernel.org email addresses. Ingo
> Molnar, Rafael Wysocki, a couple of others. But you're the one
> getting marked as spam.
I'm not going to search for rule 36 SPI.
> Somebody just hates you. I do end up checking my spam-box regularly,
> so maybe it doesn't matter.
Some spot checks are suggesting that they use gmail as their outbound
relay which I can imagine they'd like but would break some stuff for me
for non-kernel.org mail I think, it'd be a major rework to not inject
stuff via sendmail.
Hi,
On Tue, May 07, 2019 at 08:03:45PM +0900, Mark Brown wrote:
> On Mon, May 06, 2019 at 08:13:49PM -0700, Linus Torvalds wrote:
> > On Mon, May 6, 2019 at 8:02 PM Mark Brown <[email protected]> wrote:
>
> > > Everything I'm
> > > seeing is saying that Google just isn't enthusiastic about domains like
> > > kernel.org which is going an issue.
>
> > Well, there are other people who use kernel.org email addresses. Ingo
> > Molnar, Rafael Wysocki, a couple of others. But you're the one
> > getting marked as spam.
>
> I'm not going to search for rule 36 SPI.
>
> > Somebody just hates you. I do end up checking my spam-box regularly,
> > so maybe it doesn't matter.
>
> Some spot checks are suggesting that they use gmail as their outbound
> relay which I can imagine they'd like but would break some stuff for me
> for non-kernel.org mail I think, it'd be a major rework to not inject
> stuff via sendmail.
FWIW, I send out kernel.org mails via mail.kernel.org. Konstantin
added that service in 2014. You can get a password with
ssh [email protected] getsmtppass
and then use the following settings for (example for git):
[sendemail]
smtpserver = mail.kernel.org
smtpserverport = 587
smtpencryption = tls
smtpuser = <user>@kernel.org
smtppass = [randomstring]
-- Sebastian
On Mon, May 6, 2019 at 7:33 AM Mark Brown <[email protected]> wrote:
>
> spi: Updates for v5.2
Hmm. Please be more careful. Commit 1dfbf334f123 ("spi: ep93xx:
Convert to use CS GPIO descriptors") caused a new warning because it
removed a "for ()" loop, but left the now unused variable 'i' around.
I fixed it up in the merge, because I hate warnings that may hide real
problems. But I also expect maintainers to check their warnings,
exactly because the normal build is supposed to have none. So a new
warning does stand out.
Linus
The pull request you sent on Mon, 6 May 2019 23:33:01 +0900:
> https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git tags/spi-v5.2
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/9bff9dfc513bd5de72cb59f4bffb72cf0a5aa526
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker
On Tue, May 07, 2019 at 02:07:30PM +0200, Sebastian Reichel wrote:
> FWIW, I send out kernel.org mails via mail.kernel.org. Konstantin
> added that service in 2014. You can get a password with
> ssh [email protected] getsmtppass
>
> and then use the following settings for (example for git):
I'd have to send all mail out via kernel.org to do that, or persuade a
MTA to route mail differently based on contents which seems interesting
- I inject most of my mail via /usr/sbin/sendmail rather than SMTP
(including a bunch of scripts).
On Tue, May 07, 2019 at 08:08:50AM -0700, Linus Torvalds wrote:
> On Mon, May 6, 2019 at 7:33 AM Mark Brown <[email protected]> wrote:
> > spi: Updates for v5.2
> Hmm. Please be more careful. Commit 1dfbf334f123 ("spi: ep93xx:
> Convert to use CS GPIO descriptors") caused a new warning because it
> removed a "for ()" loop, but left the now unused variable 'i' around.
> I fixed it up in the merge, because I hate warnings that may hide real
> problems. But I also expect maintainers to check their warnings,
> exactly because the normal build is supposed to have none. So a new
> warning does stand out.
Sorry, I've actually got a fix for that queued but obviously didn't
manage to make sure it made it all the way through the process to the
pull request.
Hi,
On Wed, May 08, 2019 at 03:09:36PM +0900, Mark Brown wrote:
> On Tue, May 07, 2019 at 02:07:30PM +0200, Sebastian Reichel wrote:
> > FWIW, I send out kernel.org mails via mail.kernel.org. Konstantin
> > added that service in 2014. You can get a password with
>
> > ssh [email protected] getsmtppass
> >
> > and then use the following settings for (example for git):
>
> I'd have to send all mail out via kernel.org to do that, or persuade a
> MTA to route mail differently based on contents which seems interesting
> - I inject most of my mail via /usr/sbin/sendmail rather than SMTP
> (including a bunch of scripts).
I have a locally installed postfix in sender dependent relay
configuration, which does that for me:
http://www.postfix.org/SOHO_README.html#client_sasl_sender
-- Sebastian
On Wed, May 08, 2019 at 03:09:36PM +0900, Mark Brown wrote:
> On Tue, May 07, 2019 at 02:07:30PM +0200, Sebastian Reichel wrote:
>
> > FWIW, I send out kernel.org mails via mail.kernel.org. Konstantin
> > added that service in 2014. You can get a password with
>
> > ssh [email protected] getsmtppass
> >
> > and then use the following settings for (example for git):
>
> I'd have to send all mail out via kernel.org to do that, or persuade a
> MTA to route mail differently based on contents which seems interesting
> - I inject most of my mail via /usr/sbin/sendmail rather than SMTP
> (including a bunch of scripts).
I use a program called msmtp (https://marlam.de/msmtp/) to route email
to different SMTP servers based on my sender address. Once you have your
accounts configured, replace the call to the sendmail binary in your MUA
with msmtp and it'll route the email differently for you. It's included
in the package repositories for most major Linux distributions. Here's
two resources I found that show how to configure mutt and git send-email
to use msmtp:
https://hostpresto.com/community/tutorials/how-to-send-email-from-the-command-line-with-msmtp-and-mutt/
https://jordonwu.github.io/blog/2015/12/01/git-send-email-and-msmtp-config/
Once you have msmtp setup, send test emails from each of your accounts
to [email protected] to have a bot verify that your email
is setup properly (DKIM, SPF, reverse DNS, etc).
Brian
On Wed, May 08, 2019 at 12:13:01PM +0200, Sebastian Reichel wrote:
> On Wed, May 08, 2019 at 03:09:36PM +0900, Mark Brown wrote:
> > I'd have to send all mail out via kernel.org to do that, or persuade a
> > MTA to route mail differently based on contents which seems interesting
> > - I inject most of my mail via /usr/sbin/sendmail rather than SMTP
> > (including a bunch of scripts).
> I have a locally installed postfix in sender dependent relay
> configuration, which does that for me:
> http://www.postfix.org/SOHO_README.html#client_sasl_sender
I'm using exim on the central relay box which is much more painful to
configure than postfix sadly (one of these days I'll get round to
converting to Postfix since I prefer it and already use it on my client
boxes but the DKIM stuff is painful enough and there's enough stuff
using the box that it'll require me to actually sit down properly to do
something as substantial as cutting over MTAs). It's also not clear to
me that Postfix can be configured based on From rather than envelope
sender, I have used the configuration options you're pointing at for
envelope senders before but at least at that time Postfix didn't support
setting envelope sender via /usr/sbin/sendmail.