delaying postfix until/unless VPN is up/connected

2020-03-23 Thread Ranjan Maitra
Hi,

I am using postfix to deliver my work mail from a remote location. This works 
fine when I am on VPN (the postfix traffic goes through VPN then). However, it 
gets identified as spam when VPN is not up while sending the e-mail. Since most 
people do not routinely check their spam folders especially when an e-mail is 
not expected from a recipient, and since VPN does not always stay up for me, 
this presents a problem.

So, I am wondering if I it is possible to have a setup whereby postfix is 
delayed unless/until VPN is up and running. If VPN is down, then I would like 
postfix to be delayed until such time as it comes up. If it is possible, how do 
I go about doing this? Other ideas?

For the record, I am running a fully updated Fedora 31 linux distribution but 
this is likely irrelevant to the question.

Many thanks in advance for all your help and suggestions and best wishes,
Ranjan




Re: delaying postfix until/unless VPN is up/connected

2020-03-23 Thread Wietse Venema
>Ranjan Maitra:
> So, I am wondering if I it is possible to have a setup whereby
> postfix is delayed unless/until VPN is up and running. If VPN is
> down, then I would like postfix to be delayed until such time as
> it comes up. If it is possible, how do I go about doing this? Other
> ideas?

Before VPN goes down:

# postconf defer_transports=smtp
# postfix reload

After VPN comes up:

# postconf -X defer_transports
# postfix reload

Wietse


Re: delaying postfix until/unless VPN is up/connected

2020-03-23 Thread Ranjan Maitra
On Mon, 23 Mar 2020 15:05:17 -0400 (EDT) Wietse Venema  
wrote:

> >Ranjan Maitra:
> > So, I am wondering if I it is possible to have a setup whereby
> > postfix is delayed unless/until VPN is up and running. If VPN is
> > down, then I would like postfix to be delayed until such time as
> > it comes up. If it is possible, how do I go about doing this? Other
> > ideas?
>
> Before VPN goes down:
>
> # postconf defer_transports=smtp
> # postfix reload
>
> After VPN comes up:
>
> # postconf -X defer_transports
> # postfix reload
>
>   Wietse
>

Thank you for this! I am very new to this so would like some more advice. Where 
do I put this? Also, I have control over it going up but not always over it 
going down (which appears to be sometimes arbitrary). How do I do that?

Btw, in case this matters, my VPN is through Cisco's Anyconnect VPN with Okta's 
2-factor authentication. NetworkManager's openconnect VPN does not work any 
more for me because of the 2-factor authentication (or at least I could not 
figure it out).

Many thanks again and best wishes,
Ranjan



Re: delaying postfix until/unless VPN is up/connected

2020-03-23 Thread Peter

On 24/03/20 8:05 am, Wietse Venema wrote:

Ranjan Maitra:
So, I am wondering if I it is possible to have a setup whereby
postfix is delayed unless/until VPN is up and running. If VPN is
down, then I would like postfix to be delayed until such time as
it comes up. If it is possible, how do I go about doing this? Other
ideas?


Before VPN goes down:

# postconf defer_transports=smtp
# postfix reload

After VPN comes up:

# postconf -X defer_transports
# postfix reload


If he's using relayhost and postfix can't reach the nexthop shouldn't 
postfix just defer automatically without having to do this every time?



Peter


Re: delaying postfix until/unless VPN is up/connected

2020-03-23 Thread Wietse Venema
Ranjan Maitra:
> So, I am wondering if I it is possible to have a setup whereby
> postfix is delayed unless/until VPN is up and running. If VPN is
> down, then I would like postfix to be delayed until such time as
> it comes up. If it is possible, how do I go about doing this? Other
> ideas?

Wietse:
> Before VPN goes down:
>
> # postconf defer_transports=smtp
> # postfix reload
>
> After VPN comes up:
>
> # postconf -X defer_transports
> # postfix reload

Ranjan Maitra:
> Thank you for this! I am very new to this so would like some more
> advice. Where do I put this? Also, I have control over it going
> up but not always over it going down (which appears to be sometimes
> arbitrary). How do I do that?

If you want to automatically execute those commands, then you need
to run a program that periodically determines if the VPN is up, and
that invokes the above commands when the VPN status changes.

In your case, it may be sufficient to query the VPN network device
status.

Totally untested code follows:

#!/bin/sh

while :
do
ifconfig xxx | egrep 'UP|DOWN'
sleep 2
done | while read status
case "$status" in
*UP*) if [ "$prev" -ne up ]
then
prev=up
postconf -X defer_transports
postfix reload
fi;;
 *) if [ "$prev" -ne down ]
then
prev=down
postconf defer_transports=smtp
postfix reload
fi;;
esac

I have not used VPN in years, so I don't have more specific examples.

Wietse


Re: delaying postfix until/unless VPN is up/connected

2020-03-23 Thread Ranjan Maitra
On Mon, 23 Mar 2020 16:22:40 -0400 (EDT) Wietse Venema  
wrote:

> Ranjan Maitra:
> > So, I am wondering if I it is possible to have a setup whereby
> > postfix is delayed unless/until VPN is up and running. If VPN is
> > down, then I would like postfix to be delayed until such time as
> > it comes up. If it is possible, how do I go about doing this? Other
> > ideas?
>
> Wietse:
> > Before VPN goes down:
> >
> > # postconf defer_transports=smtp
> > # postfix reload
> >
> > After VPN comes up:
> >
> > # postconf -X defer_transports
> > # postfix reload
>
> Ranjan Maitra:
> > Thank you for this! I am very new to this so would like some more
> > advice. Where do I put this? Also, I have control over it going
> > up but not always over it going down (which appears to be sometimes
> > arbitrary). How do I do that?
>
> If you want to automatically execute those commands, then you need
> to run a program that periodically determines if the VPN is up, and
> that invokes the above commands when the VPN status changes.
>
> In your case, it may be sufficient to query the VPN network device
> status.
>
> Totally untested code follows:
>
> #!/bin/sh
>
> while :
> do
> ifconfig xxx | egrep 'UP|DOWN'
> sleep 2
> done | while read status
> case "$status" in
> *UP*) if [ "$prev" -ne up ]
> then
>   prev=up
>   postconf -X defer_transports
>   postfix reload
> fi;;
>  *) if [ "$prev" -ne down ]
> then
>   prev=down
>   postconf defer_transports=smtp
>   postfix reload
> fi;;
> esac
>

Thank you! I presume that this should go in as a cron job. I will try this out 
and let you know, but at least it is a good place for me to at least start if 
not more.

Many thanks again and best wishes,
Ranjan
Important Notice: This mailbox is ignored: e-mails are set to be deleted on 
receipt. Please respond to the mailing list if appropriate. For those needing 
to send personal or professional e-mail, please use appropriate addresses.



Re: delaying postfix until/unless VPN is up/connected

2020-03-23 Thread Wietse Venema
Corrected code follows (missing do/done).

Save to file, chmod +x  name-of-file, don't run this script from
cron. 

It needs to be started at boot time, or before you make a VPN
connection.

#!/bin/sh

while :
do
ifconfig xxx | egrep 'UP|DOWN'
sleep 2
done | while read status
do
case "$status" in
  *UP*) if [ "$prev" -ne up ]
then
prev=up
postconf -X defer_transports
postfix reload
fi;;
 *) if [ "$prev" -ne down ]
then
prev=down
postconf defer_transports=smtp
postfix reload
fi;;
esac
done

Wietse



Re: delaying postfix until/unless VPN is up/connected

2020-03-23 Thread Leonid Isaev
On Mon, Mar 23, 2020 at 03:36:52PM -0500, Ranjan Maitra wrote:
> I presume that this should go in as a cron job.

This depends on your distribution and VPN settings. For example, on my
ArchLinux system which uses OpenVPN, I'd make this a systemd unit that binds to
the tun network interface...

HTH,
L.

-- 
Leonid Isaev
iFAX Solutions, Inc.


Re: delaying postfix until/unless VPN is up/connected

2020-03-23 Thread Bob Proulx
Leonid Isaev wrote:
> This depends on your distribution and VPN settings. For example, on my
> ArchLinux system which uses OpenVPN, I'd make this a systemd unit that binds 
> to
> the tun network interface...

I know you said you are running Fedora but I imagine that Fedora has
something like this but in a different place.  Doesn't Fedora have a
/etc/sysconfig/network-scripts/ directory where event scripts reside?
I am sure a Fedora knowledgeable person would be able to say.

On my Debian (and therefore Ubuntu, Mint, other derivatives) I would
add a script /etc/network/if-up.d/postfix-local (in addition to the
already existing "postfix" script there) that does this when the VPN
interface comes up, and a script /etc/network/if-down.d/postfix-local
for the other end.

The packaged "postfix" scripts there are complicated by needing to
deal with every possible situation such as being a conffile in the
package removed state with the rest of the package being gone.  But
since this is your local script you don't need to worry about what
happens if Exim is actually installed instead or that someone has
diverted the directories to different locations.  You can make the
local script much simpler and focused on your needs.  But it is good
to look at the packaged scripts to get concepts and ideas.

Scripts in that directory are called when any interface changes
state.  So check that the vpn is the interface being changed.  Check
that it has gone up, or down, and perform the appropriate associated
action.

I create and debug those types of scripts by shear brute force rather
than documentation.  I create a sample script.  I put commands like
the following in it and whatever else I think I might need and no
actions.  I then bring interfaces up and down and look in the file to
see what changes have happend to the environment variables.

#!/bin/sh
exec >> /var/tmp/foo.env.out 2>&1
echo 
echo "args: $*"
env

Then knowing that information I can write the script to trigger the
actions I want when the VPN device changes state and it will all work
event driven immediately and not need to be polled by cron.  This is
what I would suggest.  But with the Fedora paths not the ones I
mention above from Debian which I was writing simply as an example.

Bob


Re: delaying postfix until/unless VPN is up/connected

2020-03-23 Thread Scott Kitterman
On Monday, March 23, 2020 7:47:25 PM EDT Bob Proulx wrote:
> On my Debian (and therefore Ubuntu, Mint, other derivatives) I would
> add a script /etc/network/if-up.d/postfix-local (in addition to the
> already existing "postfix" script there) that does this when the VPN
> interface comes up, and a script /etc/network/if-down.d/postfix-local
> for the other end.

if-up and if-down are Debian (and derivative) specific.  I don't believe it is 
shared with distros from any other lineage.

Scott K




Re: delaying postfix until/unless VPN is up/connected

2020-03-23 Thread Bob Proulx
Ranjan Maitra wrote:
> I am using postfix to deliver my work mail from a remote
> location. This works fine when I am on VPN (the postfix traffic goes
> through VPN then). However, it gets identified as spam when VPN is
> not up while sending the e-mail. Since most people do not routinely
> check their spam folders especially when an e-mail is not expected
> from a recipient, and since VPN does not always stay up for me, this
> presents a problem.
> 
> So, I am wondering if I it is possible to have a setup whereby
> postfix is delayed unless/until VPN is up and running. If VPN is
> down, then I would like postfix to be delayed until such time as it
> comes up. If it is possible, how do I go about doing this? Other
> ideas?

I have over the years used different "road warrior" laptop
configurations.  That has included the most excellent OpenVPN.  And I
also responded with a suggestion of what I would do there in another
message.  But at the moment on my laptop I am using a non-vpn port
tunneled configuration.  This allows me to do something which is
working very well for me.  YMMV.  I'll mention it because you or
someone might find it useful.

I am tunneling port 2501 on my road warrior laptop to port 25 on my
mail server.  Connections on my laptop to port 2501 pop into the
tunnel on the laptop and pop out of the tunnel connecting to Postfix
on my mail server.  Postfix sees the connection as coming from
127.0.0.1 when it pops out of the tunnel.  I set 'relayhost' this way.

  relayhost = [127.0.0.1]:2501

This has the advantage that when the port forwarding is up then my
laptop Postfix can send mail immediately.  No delays.  It is encrypted
through the port forwarded tunnel.  On my server the connection is
seen as from 127.0.0.1 and therefore is permitted without additional
authentication or authorization, those tasks being performed by my VPN
port forwarded tunnel.

And the advantage that when the vpn, port forward, or network is down,
then Postfix queues the mail locally.  It remains in the queue.  It
will be delivered when the network goes online.

As mentioned in my other message the packaged Postfix has a network
script that runs when the network state changes to online.  When that
event happens the if-up.d/postfix script calls "sendmail -q" which
triggers a queue flush as soon as the network is available for it.
The result is that I can read and respond to mail on my laptop offline
and it will queue.  Then when I later connect to a network the queued
mail transfers as soon as the network goes online.  It is very
convenient.

This works very well for me.  It's a simple configuration.

I have been vague about how I am port forwarding.  I am using AutoSSH
from https://www.harding.motd.ca/autossh/ which is clever.  But
probably not for everyone.  OpenVPN is the most industrial strength.
'sshuttle' has interesting use cases too.  I use the tool that fits
the best in each situation.

Bob

P.S. I write too much.  So stop reading at this point.  But let me
tell this story which I think is somewhat funny.  This was some many
years ago before networking was everywhere.  And back in the earlier
days when the Internet was not quite so hostile as it is now.  I was
driving across the middle of Kansas on the I-70 Interstate highway.  I
stopped at a rest area.  They had a sign up.  Complimentary WiFi
available from KDOT (Kansas Department of Transportation).  Wow!  I
could get on the Internet for a moment!  While out where nothing was
visible other than wheat fields.  What a novelty!  At the time
networking was not commonly available so this was very cool.  I got on
on the net.  I sent an email back to my wife to say where I was and
wow I had found this WiFi access point at this rest area hosted by
KDOT.  And that I was continuing on the trek.  Sent it.  Didn't think
about it again.  It was not an important message.

I did not know at the time that it though an SMTP server had accepted
the message that was not my server and that it had not been delivered.
But literally *six months later* I got a bounce return undeliverable
from that message back to me!  WAT?!  I examined it in detail.  It
turns out that while my laptop sent the mail that it had not delivered
it to my mail server where it had been configured using a very simple
configuration of "relayhost = proulx.com" or similar.  No security.
It was simply email back then.  Store and forward.

Instead it turns out that KDOT routers had intercepted and diverted
the port 25 SMTP transaction to one of their servers instead of mine.
I had not expected that.  I had not seen that ever happening before.
And then they sat on the message.  For months.  And then six months
later some admin had kicked their system and triggered a bounce of all
of the queued mail.  Which six months later was probably the best
action as delivering it would have been more confusing.

That event caused me to know that random leaf networks might be
configured very strangely indeed.  One cannot trust

Re: delaying postfix until/unless VPN is up/connected

2020-03-23 Thread Bob Proulx
Scott Kitterman wrote:
> On Monday, March 23, 2020 7:47:25 PM EDT Bob Proulx wrote:

But don't forget I also said:

> > I know you said you are running Fedora but I imagine that Fedora
> > has something like this but in a different place.  Doesn't Fedora
> > have a /etc/sysconfig/network-scripts/ directory where event
> > scripts reside?  I am sure a Fedora knowledgeable person would be
> > able to say.

> > On my Debian (and therefore Ubuntu, Mint, other derivatives) I would
> > add a script /etc/network/if-up.d/postfix-local (in addition to the
> > already existing "postfix" script there) that does this when the VPN
> > interface comes up, and a script /etc/network/if-down.d/postfix-local
> > for the other end.
> 
> if-up and if-down are Debian (and derivative) specific.  I don't
> believe it is shared with distros from any other lineage.

Right.  I said that.  But many people like Fedora.  I hear it is a
capable OS.  Therefore I assume it must have capability.  Even if you
and I do not know how it should be done ourselves.

What about /etc/sysconfig/network-scripts/ifup-post and the others?  I
see a /etc/sysconfig/network-scripts/ifup-tunnel event script.  Surely
there is a Right Place in there somewhere to insert an event driven
action?  Those appear to source a file /etc/sysconfig/network that
could be (ab)used for this purpose too.  If I had no other way then I
would wedge it in there.

I am looking at RHEL which is as close to a Fedora system as I have
available to peek into at this moment.  But I would find it very
shocking if the answer really is that Fedora does not have this
capability.

Bob


Re: delaying postfix until/unless VPN is up/connected

2020-03-23 Thread Ranjan Maitra
On Mon, 23 Mar 2020 18:46:11 -0600 Bob Proulx  wrote:

> Scott Kitterman wrote:
> > On Monday, March 23, 2020 7:47:25 PM EDT Bob Proulx wrote:
>
> But don't forget I also said:
>
> > > I know you said you are running Fedora but I imagine that Fedora
> > > has something like this but in a different place.  Doesn't Fedora
> > > have a /etc/sysconfig/network-scripts/ directory where event
> > > scripts reside?  I am sure a Fedora knowledgeable person would be
> > > able to say.
>
> > > On my Debian (and therefore Ubuntu, Mint, other derivatives) I would
> > > add a script /etc/network/if-up.d/postfix-local (in addition to the
> > > already existing "postfix" script there) that does this when the VPN
> > > interface comes up, and a script /etc/network/if-down.d/postfix-local
> > > for the other end.
> >
> > if-up and if-down are Debian (and derivative) specific.  I don't
> > believe it is shared with distros from any other lineage.
>
> Right.  I said that.  But many people like Fedora.  I hear it is a
> capable OS.  Therefore I assume it must have capability.  Even if you
> and I do not know how it should be done ourselves.
>
> What about /etc/sysconfig/network-scripts/ifup-post and the others?  I
> see a /etc/sysconfig/network-scripts/ifup-tunnel event script.  Surely
> there is a Right Place in there somewhere to insert an event driven
> action?  Those appear to source a file /etc/sysconfig/network that
> could be (ab)used for this purpose too.  If I had no other way then I
> would wedge it in there.
>
> I am looking at RHEL which is as close to a Fedora system as I have
> available to peek into at this moment.  But I would find it very
> shocking if the answer really is that Fedora does not have this
> capability.

Thanks very much for this. Yes, indeed, on Fedora 31, there is the directory 
called /etc/syconfig/network-scripts and there are scripts called ifup-* and 
ifdown-*
However, I am a little confused as to what I should do. It appears to me that 
an example such as here:
https://blog.skbali.com/2019/03/start-a-script-on-boot-using-systemd/
would be enough to get this started at boot?

Many thanks and best wishes,
Ranjan





--
Important Notice: This mailbox is ignored: e-mails are set to be deleted on 
receipt. Please respond to the mailing list if appropriate. For those needing 
to send personal or professional e-mail, please use appropriate addresses.