need a way to prevent -f option from overriding masquerade

I'm using dma with the MASQUERADE config setting, but unfortunately, it doesn't work when an application sends a message via /usr/bin/mail.

It seems that gnu mailutils (the usual mail command on ubuntu and debian) insists on invoking sendmail with the -f option, overriding dma's MASQUERADE setting with a local_username@local_hostname address. The end result is that the SMARTHOST rejects the message for having a bad SMTP MAIL FROM address.

Because of this, I wish dma had a config option to prevent -f from overriding MASQUERADE.

Update: According to Sergey Poznyakoff, there is currently no way to make mailutils invoke sendmail without the -f option, so my suspicion is confirmed. I suppose this means dma's MASQUERADE mode currently cannot work correctly with the (quite popular) mailutils implementation of mail.

Thanks for checking it out. So the question is, should MASQUERADE even override -f arguments?

I've been pondering the same question. It seems to me that the whole point of MASQUERADE is to allow mail-sending applications that are only aware of local accounts and hostnames to send mail on the internet (where those local accounts and hostnames are invalid or not meant to be exposed).

If that is the case, then I think MASQUERADE should always override -f. I suppose I could be overlooking some other use case, though, in which case maybe it would make sense to make either behavior selectable via config.

I hit this issue too, and it took a while to understand that MASQUERADE is actually a default, and not a way to force the envelope from to something that is accepted by the smarthost. I agree there should be a FORCE_MASQUERADE option, working like MASQUERADE, but always rewriting the envelope from address.

I've experienced the same problem. Another option won't hurt but would be useful.

I'm fine with making masquerade always overwrite the from address. Please submit a pull request for review.

Make MASQUERADE config setting override -f.

@corecode

@corecode this looks awesome! Is there any way to tell whether this update has made it to the Debian repository?

The one I have is:

# apt-cache policy dma
dma:
  Installed: 0.11-1+deb10u1
  Candidate: 0.11-1+deb10u1
  Version table:
 *** 0.11-1+deb10u1 500
        500 http://httpredir.debian.org/debian buster/main amd64 Packages
        100 /var/lib/dpkg/status

UPD Found it:

# man dma | grep -i masquerade
     MASQUERADE (string, default=empty)
           Masquerade the envelope-from addresses with this address/hostname.  Use this setting if mails are not accepted by destination mail servers because your sender domain is invalid.  This setting is overridden by the -f
           If ‘MASQUERADE’ does not contain a @ sign, the string is interpreted as a host name.  For example, setting ‘MASQUERADE’ to ‘john@’ on host ‘hamlet’ will send all mails as ‘john@hamlet’; setting it to ‘percolator’ will

So mine must be the old one. Dammit.

UPD Checking the source code for the unstable repository shows it has the code from 2019-08-20, while the fix was committed on 2019-08-30. Dammit.

@mehov I also published my patch as a debian/ubuntu package, which you can find here:

https://launchpad.net/~foresto/+archive/ubuntu/tweaks/+sourcepub/11494648/+listing-archive-extra

If you're familiar with debian packaging tools, you can either rebuild my ubuntu package on debian using the source files on that page, or grab debian's dma 0.12 sources and copy these files from my .debian.tar.xz file...

debian/patches/04-strong-masq.patch
debian/patches/series

...and then rebuild.

Navigation Menu

Repository navigation

need a way to prevent -f option from overriding masquerade #64

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

need a way to prevent -f option from overriding masquerade #64

Description

Activity

foresto commented on Jun 20, 2019

corecode commented on Jun 20, 2019

foresto commented on Jun 20, 2019

paride commented on Aug 16, 2019

kevin-olbrich commented on Aug 29, 2019

corecode commented on Aug 29, 2019

miftygusein commented on Aug 11, 2020

foresto commented on Aug 13, 2020

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions