Outbound gateway for Google Apps or Exchange online, how to authenticate?

[martijn.list]

Hi,

Google Apps and Exchange online allows you to relay all outgoing email
through an external mail server.

Google Apps calls this an "Outbound mail gateway":

https://support.google.com/a/answer/178333

And Microsoft calls this "Outbound Smart Hosting":

http://technet.microsoft.com/en-us/library/jj723128%28v=exchg.150%29.aspx

Both options however do not seem support any kind of authentication
(like username/password, or client side certificates). To only way to
make sure that only the Google apps or Microsoft online server is
allowed to relay it seems that you need to approve the IP ranges used by
Google and Microsoft.

The problem is that in principle this IP range might change every now
and then. I belief Google publishes their IP ranges in an SPF record so
in principle this IP range can be looked up. Not sure about Microsoft
though.

Even if you only only allow Google Apps or Exchange online ip ranges,
you still have the problem that someone else might configure your relay
servers IP as their outbound gateway. Since in that case the email comes
from Google or Microsoft, the external relay will accept the email. So
just checking for IP ranges is not enough. I guess the only solution
would be to check for sender domain and refuse to relay users from
another domain.

Has anyone on this list has any experience in setting up an outbound
gateway for Google Apps and/or Exchange online?

If so any ideas how to make sure this will work without any problems?

Kind regards,

Martijn Brinkers

-- 
DJIGZO email encryption

Re: Outbound gateway for Google Apps or Exchange online, how to authenticate?

[Robert Schetterer]

Am 27.03.2014 08:45, schrieb martijn.list:
> as anyone on this list has any experience in setting up an outbound
> gateway for Google Apps and/or Exchange online?
> 
> If so any ideas how to make sure this will work without any problems?

whatever microsoft or google does, it maybe ok to allow relay outbound
with postfix for fixed "trusted" and "controlled" ips and nets, for
dynamic ips, only allow relay with auth sasl, and maybe limit to sender
domain etc.

If relayed mails bounce by i.e forwarding strict spf domains at
recipient mailserver it works like designed.


Best Regards
MfG Robert Schetterer

-- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Franziskanerstraße 15, 81669 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Backup relay possible?

[Nikolaos Milas]

Hello,

On our gateway server, we have:

   transport_maps = hash:/etc/postfix/transportmap

   /etc/postfix/transportmap
   noa.gr  relay:[vmail.noa.gr]
   admin.noa.grrelay:[vmail.noa.gr]
   nestor.noa.gr   relay:[vmail.noa.gr]
   space.noa.grrelay:[vmail.noa.gr]
   meteo.noa.grrelay:[vmail.noa.gr]
   gein.noa.gr relay:[vmail.noa.gr]
   technet.noa.gr  relay:[vmail.noa.gr]
   astro.noa.grrelay:[vmail.noa.gr]

Is there a way to configure a "backup relay" (i.e. a secondary next 
hop), so as to, if vmail.noa.gr does not respond, then incoming mail can 
be attempted to be delivered to the backup relay (for example to 
vmail1.noa.gr)?


I understand that this complicates delivery in the sense that if the 
backup relay does not respond as well, postfix should decide what to do; 
I would think that it would keep it in the queue and retry both "relay 
points" each time, with the same sequence.


Please advise on possible ways in which we can configure such a 
secondary relay.


Thanks and best regards,
Nick

Re: Backup relay possible?

[Benny Pedersen]

Make vmail.noa.gr with multi ip then postfix will resolve it self

Else make dns split view on local servers

Avoid transport maps

Re: transport_maps "loops back to myself"

[MV]

> Wietse Venema wrote:
> In other words, RTFM.

I'd love to say I haven't read the manual and thank you for pointing
it out to me, but my OCD is too damn high, so I always read manuals.
Unfortunately this time I can't quite get my head around it to figure
it out on my own how to correctly and sanely configure postfix to use
a different smtp delivery transports for mail destined to foreign
destinations.

I believe the below is irrelevant to issue I'm trying to solve, but
I'd to understand postfix better instead of just copy+paste or get
ready-made crafted answer.
The documentation says:

...
With lookups from indexed files such as DB or DBM, or from
networked tables such as NIS, LDAP or SQL, patterns are tried *in the
order as listed below*:
user+extension@domain transport:nexthop
user@domain transport:nexthop
domain transport:nexthop
.domain transport:nexthop
* transport:nexthop
...
TCP-BASED TABLES
Each lookup operation uses the entire recipient address once.
Thus, some.domain.hierarchy is not looked up via its parent domains,
nor is user+foo@domain looked up as user@domain.
...

As far as I can tell, in my case since I'm using sing tcp-base tables
some look ups are not performed and that's fine. But there are no
mentions to the change in the order which patterns are checked.
So am I wrong to expect to see the logs showing "get bar 
foreign.tld" and "get foo  mydomain.tld" before "get *"?
As oppose to what I see now:
get *
get *
get bar  foreign.tld
get foo  mydomain.tld



Regards, Marcus

Re: Backup relay possible?

[Birta Levente]

On 27/03/2014 13:49, Nikolaos Milas wrote:

Hello,

On our gateway server, we have:

   transport_maps = hash:/etc/postfix/transportmap

   /etc/postfix/transportmap
   noa.gr  relay:[vmail.noa.gr]
   admin.noa.grrelay:[vmail.noa.gr]
   nestor.noa.gr   relay:[vmail.noa.gr]
   space.noa.grrelay:[vmail.noa.gr]
   meteo.noa.grrelay:[vmail.noa.gr]
   gein.noa.gr relay:[vmail.noa.gr]
   technet.noa.gr  relay:[vmail.noa.gr]
   astro.noa.grrelay:[vmail.noa.gr]

Is there a way to configure a "backup relay" (i.e. a secondary next 
hop), so as to, if vmail.noa.gr does not respond, then incoming mail 
can be attempted to be delivered to the backup relay (for example to 
vmail1.noa.gr)?


http://www.postfix.org/postconf.5.html#fallback_relay

--
   Levi

Re: Backup relay possible?

[Nikolaos Milas]

On 27/3/2014 2:04 μμ, Birta Levente wrote:



http://www.postfix.org/postconf.5.html#fallback_relay



Oh, thanks!

So, since the two conditions are by default fulfilled:

 * In main.cf specify "relay_transport = relay",
 * In master.cf specify "-o fallback_relay =" (i.e., empty) at the end
   of the relay entry.

...it is enough to specify in transport maps:

   noa.gr relay:[vmail.noa.gr]
   noa.gr relay:[vmail1.noa.gr]
   admin.noa.gr relay:[vmail.noa.gr]
   admin.noa.gr relay:[vmail1.noa.gr]
   ...

Right?

Thanks,
Nick

Re: transport_maps "loops back to myself"

[Wietse Venema]

MV:
> As far as I can tell, in my case since I'm using sing tcp-base tables
> some look ups are not performed and that's fine. But there are no
> mentions to the change in the order which patterns are checked.
> So am I wrong to expect to see the logs showing "get bar 
> foreign.tld" and "get foo  mydomain.tld" before "get *"?
> As oppose to what I see now:
> get *
> get *

The "*" is the documented wild-card pattern. The query result is
not expected to change, therefore it is cached once during the
initialization of a trivial-rewrite process instance.

Wietse

How to force Postfix 2.5.9 to try another MX?

[Bogdan Enache]

Hi,
I've got quite a strange problem.
A user is trying to send email to a domain, "tn.odessa.ua" which has 3 
MX servers. One of them is clearly not working, 
"notes.uptel.net[195.138.170.139]", which has a priority of 30. Checking 
the logs I see that Postfix always tries to deliver to 
"notes.uptel.net", and only that one, for the past 9 hours.


Also, "n1.uptel.net" isn't accepting connections on port 25.

But "relay.uptel.net" is accepting connections and we had a succesful 
email sent from another of our servers using that MX.


I've checked resolv.conf in chroot, it's correct. Using dig I get:

;; ANSWER SECTION:
tn.odessa.ua.   3000IN  MX  30 notes.uptel.net.
tn.odessa.ua.   3000IN  MX  5 n1.uptel.net.
tn.odessa.ua.   3000IN  MX  20 relay.uptel.net.

;; ADDITIONAL SECTION:
notes.uptel.net.438 IN  A   195.138.170.139
n1.uptel.net.   435 IN  A   195.138.160.145
relay.uptel.net.437 IN  A   195.138.160.43

Postfix is configured with:
smtp_mx_address_limit = 20
smtp_mx_session_limit = 5
(Checked using postconf -n).

I restarted Postfix and flushed the queue a few times, but there isn't 
any change. It's always trying "notes.uptel.net", never any of the other 
2 MXs.


What should I do?

Thanks.

Re: How to force Postfix 2.5.9 to try another MX?

[Robert Schetterer]

Am 27.03.2014 14:24, schrieb Bogdan Enache:
> Hi,
> I've got quite a strange problem.
> A user is trying to send email to a domain, "tn.odessa.ua" which has 3
> MX servers. One of them is clearly not working,
> "notes.uptel.net[195.138.170.139]", which has a priority of 30. Checking
> the logs I see that Postfix always tries to deliver to
> "notes.uptel.net", and only that one, for the past 9 hours.
> 
> Also, "n1.uptel.net" isn't accepting connections on port 25.
> 
> But "relay.uptel.net" is accepting connections and we had a succesful
> email sent from another of our servers using that MX.
> 
> I've checked resolv.conf in chroot, it's correct. Using dig I get:
> 
> ;; ANSWER SECTION:
> tn.odessa.ua.   3000IN  MX  30 notes.uptel.net.
> tn.odessa.ua.   3000IN  MX  5 n1.uptel.net.
> tn.odessa.ua.   3000IN  MX  20 relay.uptel.net.
> 
> ;; ADDITIONAL SECTION:
> notes.uptel.net.438 IN  A   195.138.170.139
> n1.uptel.net.   435 IN  A   195.138.160.145
> relay.uptel.net.437 IN  A   195.138.160.43
> 
> Postfix is configured with:
> smtp_mx_address_limit = 20
> smtp_mx_session_limit = 5
> (Checked using postconf -n).
> 
> I restarted Postfix and flushed the queue a few times, but there isn't
> any change. It's always trying "notes.uptel.net", never any of the other
> 2 MXs.
> 
> What should I do?
> 
> Thanks.

perhaps
quick tmp fix use a transport table with static target ip


Best Regards
MfG Robert Schetterer

-- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Franziskanerstraße 15, 81669 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: How to force Postfix 2.5.9 to try another MX?

[Wietse Venema]

Bogdan Enache:
> I restarted Postfix and flushed the queue a few times, but there isn't 
> any change. It's always trying "notes.uptel.net", never any of the other 
> 2 MXs.

The Postfix client tries a limited number of IP addresses and a limited
number of SMTP sessions.

Number of IP addresses, default: smtp_mx_address_limit = 5.
Number of SMTP sessions, default: smtp_mx_session_limit = 2.

Wietse

Re: How to force Postfix 2.5.9 to try another MX?

[Bogdan Enache]

Pe 27.03.2014 15:51, Wietse Venema a scris:

Bogdan Enache:

I restarted Postfix and flushed the queue a few times, but there isn't
any change. It's always trying "notes.uptel.net", never any of the other
2 MXs.

The Postfix client tries a limited number of IP addresses and a limited
number of SMTP sessions.

Number of IP addresses, default: smtp_mx_address_limit = 5.
Number of SMTP sessions, default: smtp_mx_session_limit = 2.

Wietse


Hi Wietse,
As I said in my first mail, it's already configured with:
smtp_mx_address_limit = 20
smtp_mx_session_limit = 5

I assumed that would be sufficient (they only have 3 MXs). I've 
increased smtp_mx_session_limit to 50 right now.




Pe 27.03.2014 15:39, Robert Schetterer a scris:

perhaps
quick tmp fix use a transport table with static target ip


Best Regards
MfG Robert Schetterer

Thanks for the idea Robert, using a static transport map worked as a 
quick fix. But I'm still not sure what happened and why.


Best regards,
Bogdan Enache

Re: Backup relay possible?

[Birta Levente]

On 27/03/2014 15:05, Nikolaos Milas wrote:

On 27/3/2014 2:04 μμ, Birta Levente wrote:



http://www.postfix.org/postconf.5.html#fallback_relay



Oh, thanks!

So, since the two conditions are by default fulfilled:

* In main.cf specify "relay_transport = relay",
* In master.cf specify "-o fallback_relay =" (i.e., empty) at the end
of the relay entry.

...it is enough to specify in transport maps:

noa.gr relay:[vmail.noa.gr]
noa.gr relay:[vmail1.noa.gr]
admin.noa.gr relay:[vmail.noa.gr]
admin.noa.gr relay:[vmail1.noa.gr]
...


Not really IMHO

AFAIK since you have two entries with same key in transport map, postfix 
will choose the first.


I think this is the way:

main.cf:
fallback_relay=[vmail1.noa.gr]

transport_map:
noa.gr relay:[vmail.noa.gr]
admin.noa.gr relay:[vmail.noa.gr]


--
   Levi

Re: How to force Postfix 2.5.9 to try another MX?

[Robert Schetterer]

Am 27.03.2014 14:58, schrieb Bogdan Enache:
> Pe 27.03.2014 15:51, Wietse Venema a scris:
>> Bogdan Enache:
>>> I restarted Postfix and flushed the queue a few times, but there isn't
>>> any change. It's always trying "notes.uptel.net", never any of the other
>>> 2 MXs.
>> The Postfix client tries a limited number of IP addresses and a limited
>> number of SMTP sessions.
>>
>> Number of IP addresses, default: smtp_mx_address_limit = 5.
>> Number of SMTP sessions, default: smtp_mx_session_limit = 2.
>>
>> Wietse
> 
> Hi Wietse,
> As I said in my first mail, it's already configured with:
> smtp_mx_address_limit = 20
> smtp_mx_session_limit = 5
> 
> I assumed that would be sufficient (they only have 3 MXs). I've
> increased smtp_mx_session_limit to 50 right now.
> 
> 
> 
> Pe 27.03.2014 15:39, Robert Schetterer a scris:
>> perhaps
>> quick tmp fix use a transport table with static target ip
>>
>>
>> Best Regards
>> MfG Robert Schetterer
>>
> Thanks for the idea Robert, using a static transport map worked as a
> quick fix. But I'm still not sure what happened and why.

as far in understand Wietse
dont change default limits without very good reasons



>> Number of IP addresses, default: smtp_mx_address_limit = 5.
>> Number of SMTP sessions, default: smtp_mx_session_limit = 2

should be fine in your described case


> 
> Best regards,
> Bogdan Enache
> 



Best Regards
MfG Robert Schetterer

-- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Franziskanerstraße 15, 81669 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

RE: Backup relay possible?

[James Day]

> -Original Message-
> From: owner-postfix-us...@postfix.org [mailto:owner-postfix-
> us...@postfix.org] On Behalf Of Nikolaos Milas
> Sent: 27 March 2014 14:27
> To: postfix-users@postfix.org
> Subject: Re: Backup relay possible?
> 
> On 27/3/2014 4:10 μμ, Birta Levente wrote:
> 
> > Not really IMHO
> >
> > AFAIK since you have two entries with same key in transport map,
> > postfix will choose the first.
> >
> > I think this is the way:
> >
> > main.cf:
> > fallback_relay=[vmail1.noa.gr]
> >
> > transport_map:
> > noa.gr relay:[vmail.noa.gr]
> > admin.noa.gr relay:[vmail.noa.gr]
> 
> Hmm, yes; reading the docs, I understand you are right. This is the way it
> should be. (It was careless on my part to draw hastily a wrong
> conclusion.)
> 
> Yet, this means that a fallback relay will be common for all entries in
> transport_maps (which is fine in my case), but there is no way to define
> fallback relays per domain as in transport_maps?
> 
> Nick

What I have done to mitigate this issue is to setup a DNS server with internal 
use only zones.

The transport map would therefore read similar to the following:

noa.gr relay:noa.gr.local

I have then configured A records for the multiple relay destinations, queries 
are then balanced in a DNS round robin fashion.

It's perhaps not the most elegant solution but *touch wood* it hasn't caused me 
any issues.

Kind regards,

James Day

Re: Backup relay possible?

[Nikolaos Milas]

On 27/3/2014 4:10 μμ, Birta Levente wrote:


Not really IMHO

AFAIK since you have two entries with same key in transport map, 
postfix will choose the first.


I think this is the way:

main.cf:
fallback_relay=[vmail1.noa.gr]

transport_map:
noa.gr relay:[vmail.noa.gr]
admin.noa.gr relay:[vmail.noa.gr] 


Hmm, yes; reading the docs, I understand you are right. This is the way 
it should be. (It was careless on my part to draw hastily a wrong 
conclusion.)


Yet, this means that a fallback relay will be common for all entries in 
transport_maps (which is fine in my case), but there is no way to define 
fallback relays per domain as in transport_maps?


Nick

Re: Reject client from domains without MX records

[Pau Peris]

Hi,

i'm really getting nuts trying to get is running.

The current behavior is:
* An authenticated user can login as user f...@example.com and then send an
email using from/sender address b...@example2.com
* When another server i have, also running a Postfix 2.11, which relays
emails on the main server tries to send an email the local user sending the
email must match the from/sender address. If not the following message
appears "Sender address rejected: not owned by user...". It looks like the
desired behavior only works for relaying.

Here's what happens when i fake a from address through telnet
https://gist.github.com/sibok/30d7b1085ee6eb26167c

Here's the telnet sequence
https://gist.github.com/sibok/2540ad0ed0e7dde13311

here's master.cf just in case an edit is needed
https://gist.github.com/sibok/7d10c8d267170f4deb43

I hope someone can give some bits of help.

Thanks


On Wed, Mar 26, 2014 at 9:22 PM, Pau Peris  wrote:

>
> Hello again,
>
> i read carefully the explanation given by rhsoft and also went to postconf
> doc page -  http://www.postfix.org/postconf.5.html -to be able to
> understand each one of the statements i was setting up. It really looks
> pretty easy but i think i'm bypassing something because i'm not able to
> reject senders based on:
> * The sender/from address is not the one used to login/authenticate.
> * The sender/from address does not exist.
>
> I'm posting bellow my current Postfix setup in hope someone can help to
> find the error:
>
> $ postconf |grep mail_version
> mail_version = 2.11.0
>
> $ postconf -n
> https://gist.github.com/sibok/df8c8fc0d85785978c85
>
>
> Here's the output shown at /var/log/mail.log
> https://gist.github.com/sibok/8e910f54ba5b1a9ea05b
>
> I enabled MySQL SQL Query logs so that's what i seen when trying to send
> from w...@blog.example.com to p...@example.com where example.com is a valid
> domain, able to receive emails, and blog.example.com is a valid CNAME
> which is not able to receive emails so the following address
> w...@blog.example.com does not exists.
> https://gist.github.com/sibok/ef6a417d10ddf20bd242
>
>
> On Tue, Mar 25, 2014 at 12:07 AM, Pau Peris  wrote:
>
>> Hundred thanks!! Really great help, tomorrow gonna put it all together
>> and solve the issue.
>>
>> Good night!
>>
>>
>> On Mon, Mar 24, 2014 at 9:06 PM, li...@rhsoft.net wrote:
>>
>>>
>>>
>>> Am 24.03.2014 20:54, schrieb Pau Peris:
>>> > I'm wondering why are you setting the following policies under
>>> recipient restrictions
>>> > and not under sender restrictions? Maybe it's more efficient?
>>> >
>>> > reject_non_fqdn_sender
>>> > reject_unlisted_sender
>>> > reject_authenticated_sender_login_mismatch
>>>
>>> because with "smtpd_delay_reject" which is default for
>>> good reasons it does not matter and the configuration
>>> is easier to understand as well as specific overrides
>>> are better to manage
>>>
>>> >  reject_non_fqdn_sender
>>> >  reject_unlisted_sender
>>> >  reject_authenticated_sender_login_mismatch
>>> >
>>> > Last, what do you think about reject_unverified_sender? Is it a
>>> resources drainer?
>>>
>>> it may lead to blacklisting because you always make a sending
>>> attempt and in case of forged senders you do that to servers
>>> never tried to send a message to you
>>
>>

Re: Backup relay possible?

[Birta Levente]

On 27/03/2014 16:26, Nikolaos Milas wrote:

On 27/3/2014 4:10 μμ, Birta Levente wrote:


Not really IMHO

AFAIK since you have two entries with same key in transport map, 
postfix will choose the first.


I think this is the way:

main.cf:
fallback_relay=[vmail1.noa.gr]

transport_map:
noa.gr relay:[vmail.noa.gr]
admin.noa.gr relay:[vmail.noa.gr] 


Hmm, yes; reading the docs, I understand you are right. This is the 
way it should be. (It was careless on my part to draw hastily a wrong 
conclusion.)


Yet, this means that a fallback relay will be common for all entries 
in transport_maps (which is fine in my case), but there is no way to 
define fallback relays per domain as in transport_maps?


I'm not sure and this is not tested, but maybe you can:

transport_map:
noa.gr relay1:[vmail.noa.gr]
admin.noa.gr relay2:[vmail.noa.gr]

add to master.cf:
relay1 unix - - n - - smtp
-o fallback_relay=[firstwhateverhost]
relay2 unix - - n - - smtp
-o fallback_relay=[secondwhateverhost]

--
   Levi

Re: transport_maps "loops back to myself"

[Viktor Dukhovni]

On Thu, Mar 27, 2014 at 12:04:34PM +, MV wrote:

> As far as I can tell, in my case since I'm using sing tcp-base tables
> some look ups are not performed and that's fine. But there are no
> mentions to the change in the order which patterns are checked.
> So am I wrong to expect to see the logs showing "get bar 
> foreign.tld" and "get foo  mydomain.tld" before "get *"?
> As oppose to what I see now:
> get *
> get *
> get bar  foreign.tld
> get foo  mydomain.tld

The documentation describes semantic precedence order in which
results are used.  With cached results, order of use is not
necessarily the same as order of lookup.  When you're looking at
low level activity logs you encounter implementation details
which are not fixed and hence not documented.

-- 
Viktor.

Re: Backup relay possible?

[Nikolaos Milas]

On 27/3/2014 4:32 μμ, James Day wrote:


noa.gr relay:noa.gr.local

I have then configured A records for the multiple relay destinations, queries 
are then balanced in a DNS round robin fashion.


Yes, I undertand. However, we don't want balancing (our traffic is low - 
but we want failover).


In my case, this scenario could be implemented by using a very low TTL 
for vmail.noa.gr and then use a script to monitor target and, in case it 
does not respond, then update the A record to point to another IP address.


This assumes that Postfix observes the TTL for DNS lookups (on names 
used in transport maps).


However, in my case I would not go for this solution because we want 
vmail and vmail1 to have different host names (they include Dovecot IMAP 
servers replicated using dsync). They cannot behave to others as being 
the same host.


One thing that could be done would be to monitor vmail.noa.gr on the 
gateway servers and if it does not respond, then use a script to update 
transport maps and reload postfix. It does not sound very elegant to me...


(Nor can we employ multiple IP addresses per server; it is a VPS service 
offering a single IP address per VM.)


Nick

Re: Backup relay possible?

[Robert Sander]

On 27.03.2014 16:01, Nikolaos Milas wrote:
> On 27/3/2014 4:32 μμ, James Day wrote:
> 
>> noa.gr relay:noa.gr.local
>>
>> I have then configured A records for the multiple relay destinations, 
>> queries are then balanced in a DNS round robin fashion.
> 
> Yes, I undertand. However, we don't want balancing (our traffic is low - 
> but we want failover).

You do not need A records, but you can instead add MX records with
priority. This way your use case is implemented.

Regards
-- 
Robert Sander
Heinlein Support GmbH
Schwedter Str. 8/9b, 10119 Berlin

http://www.heinlein-support.de

Tel: 030 / 405051-43
Fax: 030 / 405051-19

Zwangsangaben lt. §35a GmbHG:
HRB 93818 B / Amtsgericht Berlin-Charlottenburg,
Geschäftsführer: Peer Heinlein -- Sitz: Berlin



signature.asc
Description: OpenPGP digital signature

Re: Outbound gateway for Google Apps or Exchange online, how to authenticate?

[Viktor Dukhovni]

On Thu, Mar 27, 2014 at 08:45:01AM +0100, martijn.list wrote:

> Has anyone on this list has any experience in setting up an outbound
> gateway for Google Apps and/or Exchange online?

I set up Google Apps some years back, but have switched jobs since
and have forgotten some of the details.  We definitely put in
counter-measures that prevent other Google Apps customers from
relaying via our outbound servers.  Google should be able to tell
you about available options for that.  At the very least we had:

* Google Apps outbound flow was to port 587 with STARTTLS via
  a dedicated set of Postfix machines.

* The envelope sender domain was restricted to our Google
  Apps domain, and we used reject_unlisted_sender.

* We were "big enough" to ask them to use client certificates
  to authenticate to the outbound server.  We had a long-standing
  feature request to allow us to provision these by uploading a
  PKCS12 or similar key + cert bundle via the domain administrator
  interface, so that client certs would be per customer, not global
  for Google Apps.  Without this feature they notified us before
  deploying new client certs (which was a nuisance for them and
  us).  Don't know whether the requested client cert support got
  implemented.  So $previous_employer may still be relying on
  Google's default client certs (which unlike the sender domain
  are not client specific).

* We also asked Google to authenticate our server's TLS cert.

* We also operated our own inbound MX hosts, and used Google
  Apps only as a mailstore, not an MX provider.  Envelope
  rewriting rules kept the mail flows from looping (the
  internal mailbox address of a Google Apps user was
  a custom domain, which was rewritten back to the 
  primary address in smtp_generic_maps during hand-off
  to Google's relay).

That was all then, things may be different now, ideally better,
with more options available, but things don't always improve.
Sometimes the simplest options for the mass-market become the only
options.

-- 
Viktor.

Re: Backup relay possible?

[Nikolaos Milas]

On 27/3/2014 5:04 μμ, Robert Sander wrote:


You do not need A records, but you can instead add MX records with
priority. This way your use case is implemented.


No, these are not MXs. They are internal (final destination) servers. 
MXs are gateway servers relaying to the internal one (for which we are 
trying to setup failover).


Nick

Re: Backup relay possible?

[Nikolaos Milas]

On 27/3/2014 4:47 μμ, Birta Levente wrote:


I'm not sure and this is not tested, but maybe you can:

transport_map:
noa.gr relay1:[vmail.noa.gr]
admin.noa.gr relay2:[vmail.noa.gr]

add to master.cf:
relay1 unix - - n - - smtp
-o fallback_relay=[firstwhateverhost]
relay2 unix - - n - - smtp
-o fallback_relay=[secondwhateverhost] 


Interesting! It might work. I'll try to find an opportunity to test it.

Yet, IMHO it might be a good idea for some future version to support 
full lookup tables in fallback_relay e.g. in the form (just speculating):


---
fallback_relay_map:
---
noa.gr relay:[vmail1.noa.gr,vmail2.noa.gr]
tech.noa.gr relay:[vmail1.noa.gr,vmail5.noa.gr]
...

All the best,
Nick

Re: How to force Postfix 2.5.9 to try another MX?

[Viktor Dukhovni]

On Thu, Mar 27, 2014 at 03:24:14PM +0200, Bogdan Enache wrote:

> A user is trying to send email to a domain, "tn.odessa.ua" which has 3 MX
> servers. One of them is clearly not working,
> "notes.uptel.net[195.138.170.139]", which has a priority of 30. Checking the
> logs I see that Postfix always tries to deliver to "notes.uptel.net", and
> only that one, for the past 9 hours.

You are misinterpreting your logs, which you have not posted.
Postfix is actually trying all the MX hosts, you're only looking
at the results with the *final* MX which is where delivery error
is reported after trying all the others.

You don't need to change any of the session or address limits, they
are just fine.

Try the attached "collate" script to look at complete transaction
logs with all related connection attempts, ...

# perl collate your.mail.log.file |
perl -ne '
BEGIN {$/ = "\n\n"; $domain = shift(@ARGV);}
print if m{\@\Q$domain\E>}o;' tn.odessa.ua |
less

-- 
Viktor.
#! /usr/pkg/bin/perl

use strict;
use warnings;

# Postfix delivery agents
my @agents = qw(discard error lmtp local pipe smtp virtual);

my $instre = qr{(?x)
\A  # Absolute line start
(?:\S+ \s+){3}  # Timestamp, adjust for other time formats
\S+ \s+ # Hostname
(postfix(?:-\S+)?)/ # postfix instance
};

my $cmdpidre = qr{(?x)
\G  # Continue from previous match
(\S+)\[(\d+)\]:\s+  # command[pid]:
};

my %smtpd;
my %smtp;
my %transaction;
my $i = 0;
my %seqno;

my %isagent = map { ($_, 1) } @agents;

while (<>) {
next unless m{$instre}ogc; my $inst = $1;
next unless m{$cmdpidre}ogc; my $command = $1; my $pid = $2;

if ($command eq "smtpd") {
if (m{\Gconnect from }gc) {
# Start new log
$smtpd{$pid}->{"log"} = $_; next;
}

$smtpd{$pid}->{"log"} .= $_;

if (m{\G(\w+): client=}gc) {
# Fresh transaction 
my $qid = "$inst/$1";
$smtpd{$pid}->{"qid"} = $qid;
$transaction{$qid} = $smtpd{$pid}->{"log"};
$seqno{$qid} = ++$i;
next;
}

my $qid = $smtpd{$pid}->{"qid"};
$transaction{$qid} .= $_
if (defined($qid) && exists $transaction{$qid});
delete $smtpd{$pid} if (m{\Gdisconnect from}gc);
next;
}

if ($command eq "pickup") {
if (m{\G(\w+): uid=}gc) {
my $qid = "$inst/$1";
$transaction{$qid} = $_;
$seqno{$qid} = ++$i;
}
next;
}

# bounce(8) logs transaction start after cleanup(8) already logged
# the message-id, so the cleanup log entry may be first
#
if ($command eq "cleanup") {
next unless (m{\G(\w+): }gc);
my $qid = "$inst/$1";
$transaction{$qid} .= $_;
next;
}

if ($command eq "qmgr") {
next unless (m{\G(\w+): }gc);
my $qid = "$inst/$1";
if (defined($transaction{$qid})) {
$transaction{$qid} .= $_;
if (m{\Gremoved$}gc) {
print delete $transaction{$qid}, "\n";
}
}
next;
}

# Save pre-delivery messages for smtp(8) and lmtp(8)
#
if ($command eq "smtp" || $command eq "lmtp") {
$smtp{$pid} .= $_;

if (m{\G(\w+): to=}gc) {
my $qid = "$inst/$1";
if (defined($transaction{$qid})) {
$transaction{$qid} .= $smtp{$pid};
}
delete $smtp{$pid};
}
next;
}

if ($command eq "bounce") {
if (m{\G(\w+): .*? notification: (\w+)$}gc) {
my $qid = "$inst/$1";
my $newid = "$inst/$2";
if (defined($transaction{$qid})) {
$transaction{$qid} .= $_;
}
$transaction{$newid} =
$_ . $transaction{$newid};
}
next;
}

if ($isagent{$command}) {
if (m{\G(\w+): to=}gc) {
my $qid = "$inst/$1";
if (defined($transaction{$qid})) {
$transaction{$qid} .= $_;
}
}
next;
}
}

# Dump logs of incomplet

Re: How to force Postfix 2.5.9 to try another MX?

[Ralf Hildebrandt]

* Viktor Dukhovni :
> On Thu, Mar 27, 2014 at 03:24:14PM +0200, Bogdan Enache wrote:
> 
> > A user is trying to send email to a domain, "tn.odessa.ua" which has 3 MX
> > servers. One of them is clearly not working,
> > "notes.uptel.net[195.138.170.139]", which has a priority of 30. Checking the
> > logs I see that Postfix always tries to deliver to "notes.uptel.net", and
> > only that one, for the past 9 hours.
> 
> You are misinterpreting your logs, which you have not posted.
> Postfix is actually trying all the MX hosts, you're only looking
> at the results with the *final* MX which is where delivery error
> is reported after trying all the others.

I also get this wrong from time to time :)

-- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Franziskanerstraße 15, 81669 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: Backup relay possible?

[Robert Sander]

On 27.03.2014 16:09, Nikolaos Milas wrote:
> On 27/3/2014 5:04 μμ, Robert Sander wrote:
> 
>> You do not need A records, but you can instead add MX records with
>> priority. This way your use case is implemented.
> 
> No, these are not MXs. They are internal (final destination) servers. 
> MXs are gateway servers relaying to the internal one (for which we are 
> trying to setup failover).

I know that they are not "official" MX. The whole point is that you
create an internal domain name with two MX records pointing to these
servers. This is then used in your transport map and nowhere else.

Regards
-- 
Robert Sander
Heinlein Support GmbH
Schwedter Str. 8/9b, 10119 Berlin

http://www.heinlein-support.de

Tel: 030 / 405051-43
Fax: 030 / 405051-19

Zwangsangaben lt. §35a GmbHG:
HRB 93818 B / Amtsgericht Berlin-Charlottenburg,
Geschäftsführer: Peer Heinlein -- Sitz: Berlin



signature.asc
Description: OpenPGP digital signature

Re: Domain masquerading, but not for local

[William Wilhelm]

Thanks Victor—I solved this by diving in the deep end with multiple postfix 
instances. The main instance accepts incoming mail and delivers any 
local-bound, then smtp_generic_maps everything else (to remove the unwanted 
hostname from host.example.com) and relays to the secondary instance. This 
instance delivers the virtual-bound mail and relays everything else to my ISP.


Cheers for responding.


On 26 March 2014 6:02:49 pm Viktor Dukhovni  wrote:


On Wed, Mar 26, 2014 at 10:12:10AM +0200, William Wilhelm wrote:

> Mail sent to a local user (such as r...@host.example.com), too, has the
> sender listed as w...@example.com?not good, because a reply will be directed
> to my virtual inbox and not my local inbox. What I would is for the sender
> to be w...@host.example.com, in this case.

http://www.postfix.org/SOHO_README.html#fantasy
http://www.postfix.org/postconf.5.html#smtp_generic_maps

> I am using masquerade_domains to get the effect of rewriting the sender fqdn
> from host.example.com to just example.com, but I don't want this rewriting
> to occur for mail between local mailboxes. I have tried smtp_generic_maps
> instead which for me will rewrite the sender for mail to gmail.com but not
> mail to a virtual address.

Header address rewriting depends the transport used to deliver the
message (smtp or not), and not on the input recipient address.

If the virtual alias recipients are delivered locally, header
addresses will be in local form, if remotely in remote form.  What's
wrong with this?  Perhaps you should simplify your design.

--
Viktor.

Re: Backup relay possible?

[Nikolaos Milas]

On 27/3/2014 6:18 μμ, Robert Sander wrote:


I know that they are not "official" MX. The whole point is that you
create an internal domain name with two MX records pointing to these
servers. This is then used in your transport map and nowhere else.


Hmm, interesting. It sounds a good idea!

Thank you!

All the best,
Nick

Re: transport_maps "loops back to myself"

[MV]

>Wietse:
>> MV:
>> As far as I can tell, in my case since I'm using sing tcp-base tables
>> some look ups are not performed and that's fine. But there are no
>> mentions to the change in the order which patterns are checked.
>> So am I wrong to expect to see the logs showing "get bar 
>> foreign.tld" and "get foo  mydomain.tld" before "get *"?
>> As oppose to what I see now:
>> get *
>> get *
>
> The "*" is the documented wild-card pattern. The query result is
> not expected to change, therefore it is cached once during the
> initialization of a trivial-rewrite process instance.

Thanks for explaining that.
Got a much better picture now (and the of the diagrams at
http://www.postfix.org/OVERVIEW.html also helped)


Going back to my original question...

Lets say I have "transport_maps = hash:/etc/postfix/transport", and
the contents of /etc/postfix/transport are as follows:
# Begin /etc/postfix/transport
mydomain.ltd:
.mydomain.ltd   :
*   smtpX
# End /etc/postfix/transport

And in the master.cf file I have
# ---%<
smtpXunix--n--smtp
-o myhostname=X.mydomain.tld
-o smtp_helo_name=mx1.mydomain.tld
-o smtp_bind_address=1.1.1.1
-o syslog_name=smtpX

smtpYunix--n--smtp
-o myhostname=Y.mydomain.tld
-o smtp_helo_name=mx2.mydomain.tld
-o smtp_bind_address=2.2.2.2
-o syslog_name=smtpY
# --->%

The config above should work as expected.
Now going a step further, how can I split the "*" (all non-local)
between smtpX and smtpY (without running multiple postfix instances) ?
Something like ...

mydomain.ltd:
.mydomain.ltd   :
*   smtpX
*   smtpY

Re: transport_maps "loops back to myself"

[Viktor Dukhovni]

On Thu, Mar 27, 2014 at 04:50:25PM +, MV wrote:

> Now going a step further, how can I split the "*" (all non-local)
> between smtpX and smtpY (without running multiple postfix instances) ?
> Something like ...
> 
> mydomain.ltd:
> .mydomain.ltd   :
> *   smtpX
> *   smtpY

No.  To get round-robit results, you need a dynamic transport reply.
Thus socketmap or similar, with the replies provided by a program, not
a fixed key->value table.

Furthermore, because "*" is cached, you really don't want to use
"*" at all for dynamic transport resolution.

I answered your question upthread, use:

sender_dependent_default_transport_maps

For some reason you're still looking elsewhere...

-- 
Viktor.

Re: Reject client from domains without MX records

[Pau Peris]

If i try to spoof email/sender address through Mozilla Thunderbird i get
the same error message as the one when relaying : Sender
address rejected: not owned by user us...@example.com; So it looks like the
issue only exists when working locally like through the webmail solution.


On Thu, Mar 27, 2014 at 3:37 PM, Pau Peris  wrote:

> Hi,
>
> i'm really getting nuts trying to get is running.
>
> The current behavior is:
> * An authenticated user can login as user f...@example.com and then send
> an email using from/sender address b...@example2.com
> * When another server i have, also running a Postfix 2.11, which relays
> emails on the main server tries to send an email the local user sending the
> email must match the from/sender address. If not the following message
> appears "Sender address rejected: not owned by user...". It looks like the
> desired behavior only works for relaying.
>
> Here's what happens when i fake a from address through telnet
> https://gist.github.com/sibok/30d7b1085ee6eb26167c
>
> Here's the telnet sequence
> https://gist.github.com/sibok/2540ad0ed0e7dde13311
>
> here's master.cf just in case an edit is needed
> https://gist.github.com/sibok/7d10c8d267170f4deb43
>
> I hope someone can give some bits of help.
>
> Thanks
>
>
> On Wed, Mar 26, 2014 at 9:22 PM, Pau Peris  wrote:
>
>>
>> Hello again,
>>
>> i read carefully the explanation given by rhsoft and also went to postconf
>> doc page -  http://www.postfix.org/postconf.5.html -to be able to
>> understand each one of the statements i was setting up. It really looks
>> pretty easy but i think i'm bypassing something because i'm not able to
>> reject senders based on:
>> * The sender/from address is not the one used to login/authenticate.
>> * The sender/from address does not exist.
>>
>> I'm posting bellow my current Postfix setup in hope someone can help to
>> find the error:
>>
>> $ postconf |grep mail_version
>> mail_version = 2.11.0
>>
>> $ postconf -n
>> https://gist.github.com/sibok/df8c8fc0d85785978c85
>>
>>
>> Here's the output shown at /var/log/mail.log
>> https://gist.github.com/sibok/8e910f54ba5b1a9ea05b
>>
>> I enabled MySQL SQL Query logs so that's what i seen when trying to send
>> from w...@blog.example.com to p...@example.com where example.com is a valid
>> domain, able to receive emails, and blog.example.com is a valid CNAME
>> which is not able to receive emails so the following address
>> w...@blog.example.com does not exists.
>> https://gist.github.com/sibok/ef6a417d10ddf20bd242
>>
>>
>> On Tue, Mar 25, 2014 at 12:07 AM, Pau Peris  wrote:
>>
>>> Hundred thanks!! Really great help, tomorrow gonna put it all together
>>> and solve the issue.
>>>
>>> Good night!
>>>
>>>
>>> On Mon, Mar 24, 2014 at 9:06 PM, li...@rhsoft.net wrote:
>>>


 Am 24.03.2014 20:54, schrieb Pau Peris:
 > I'm wondering why are you setting the following policies under
 recipient restrictions
 > and not under sender restrictions? Maybe it's more efficient?
 >
 > reject_non_fqdn_sender
 > reject_unlisted_sender
 > reject_authenticated_sender_login_mismatch

 because with "smtpd_delay_reject" which is default for
 good reasons it does not matter and the configuration
 is easier to understand as well as specific overrides
 are better to manage

 >  reject_non_fqdn_sender
 >  reject_unlisted_sender
 >  reject_authenticated_sender_login_mismatch
 >
 > Last, what do you think about reject_unverified_sender? Is it a
 resources drainer?

 it may lead to blacklisting because you always make a sending
 attempt and in case of forged senders you do that to servers
 never tried to send a message to you
>>>
>>>


-- 
*Pau Peris Rodriguez*
*Chief Executive Officer (CEO)*
Tel: 669650292
C/Balmes 211, Principal Segunda
Barcelona 08006
http://www.webeloping.es

Aquest correu electrònic conté informació de caràcter confidencial dirigida
exclusivament al seu/s destinatari/s en còpia present. Tant mateix, queda
prohibida la seva divulgació, copia o distribució a tercers sense prèvia
autorització escrita per part de Pau Peris Rodriguez. En cas d'haver rebut
aquesta informació per error, es demana que es notifiqui
immediatament d'aquesta circumstancia mitjançant la direcció electrònica
del emissor.

Re: Reject client from domains without MX records

[Pau Peris]

After doing another try and looking carefully at the mail.log file i
realize that after the first attempt to reject the email i finally gets
delivered. https://gist.github.com/sibok/82f84dcc71bfa75deeeb

Hope someone can help. Thanks!


On Thu, Mar 27, 2014 at 6:52 PM, Pau Peris  wrote:

> If i try to spoof email/sender address through Mozilla Thunderbird i get
> the same error message as the one when relaying :
> Sender address rejected: not owned by user us...@example.com; So it looks
> like the issue only exists when working locally like through the webmail
> solution.
>
>
> On Thu, Mar 27, 2014 at 3:37 PM, Pau Peris  wrote:
>
>> Hi,
>>
>> i'm really getting nuts trying to get is running.
>>
>> The current behavior is:
>> * An authenticated user can login as user f...@example.com and then send
>> an email using from/sender address b...@example2.com
>> * When another server i have, also running a Postfix 2.11, which relays
>> emails on the main server tries to send an email the local user sending the
>> email must match the from/sender address. If not the following message
>> appears "Sender address rejected: not owned by user...". It looks like the
>> desired behavior only works for relaying.
>>
>> Here's what happens when i fake a from address through telnet
>> https://gist.github.com/sibok/30d7b1085ee6eb26167c
>>
>> Here's the telnet sequence
>> https://gist.github.com/sibok/2540ad0ed0e7dde13311
>>
>> here's master.cf just in case an edit is needed
>> https://gist.github.com/sibok/7d10c8d267170f4deb43
>>
>> I hope someone can give some bits of help.
>>
>> Thanks
>>
>>
>> On Wed, Mar 26, 2014 at 9:22 PM, Pau Peris  wrote:
>>
>>>
>>> Hello again,
>>>
>>> i read carefully the explanation given by rhsoft and also went to
>>> postconf
>>> doc page -  http://www.postfix.org/postconf.5.html -to be able to
>>> understand each one of the statements i was setting up. It really looks
>>> pretty easy but i think i'm bypassing something because i'm not able to
>>> reject senders based on:
>>> * The sender/from address is not the one used to login/authenticate.
>>> * The sender/from address does not exist.
>>>
>>> I'm posting bellow my current Postfix setup in hope someone can help to
>>> find the error:
>>>
>>> $ postconf |grep mail_version
>>> mail_version = 2.11.0
>>>
>>> $ postconf -n
>>> https://gist.github.com/sibok/df8c8fc0d85785978c85
>>>
>>>
>>> Here's the output shown at /var/log/mail.log
>>> https://gist.github.com/sibok/8e910f54ba5b1a9ea05b
>>>
>>> I enabled MySQL SQL Query logs so that's what i seen when trying to send
>>> from w...@blog.example.com to p...@example.com where example.com is a
>>> valid domain, able to receive emails, and blog.example.com is a valid
>>> CNAME which is not able to receive emails so the following address
>>> w...@blog.example.com does not exists.
>>> https://gist.github.com/sibok/ef6a417d10ddf20bd242
>>>
>>>
>>> On Tue, Mar 25, 2014 at 12:07 AM, Pau Peris  wrote:
>>>
 Hundred thanks!! Really great help, tomorrow gonna put it all together
 and solve the issue.

 Good night!


 On Mon, Mar 24, 2014 at 9:06 PM, li...@rhsoft.net wrote:

>
>
> Am 24.03.2014 20:54, schrieb Pau Peris:
> > I'm wondering why are you setting the following policies under
> recipient restrictions
> > and not under sender restrictions? Maybe it's more efficient?
> >
> > reject_non_fqdn_sender
> > reject_unlisted_sender
> > reject_authenticated_sender_login_mismatch
>
> because with "smtpd_delay_reject" which is default for
> good reasons it does not matter and the configuration
> is easier to understand as well as specific overrides
> are better to manage
>
> >  reject_non_fqdn_sender
> >  reject_unlisted_sender
> >  reject_authenticated_sender_login_mismatch
> >
> > Last, what do you think about reject_unverified_sender? Is it a
> resources drainer?
>
> it may lead to blacklisting because you always make a sending
> attempt and in case of forged senders you do that to servers
> never tried to send a message to you


>
>
> --
> *Pau Peris Rodriguez*
> *Chief Executive Officer (CEO)*
> Tel: 669650292
> C/Balmes 211, Principal Segunda
> Barcelona 08006
> http://www.webeloping.es
>
> Aquest correu electrònic conté informació de caràcter confidencial
> dirigida exclusivament al seu/s destinatari/s en còpia present. Tant
> mateix, queda prohibida la seva divulgació, copia o distribució a tercers
> sense prèvia autorització escrita per part de Pau Peris Rodriguez. En
> cas d'haver rebut aquesta informació per error, es demana que es notifiqui
> immediatament d'aquesta circumstancia mitjançant la direcció electrònica
> del emissor.
>



-- 
*Pau Peris Rodriguez*
*Chief Executive Officer (CEO)*
Tel: 669650292
C/Balmes 211, Principal Segunda
Barcelona 08006
http://www.webeloping.es

Aquest correu electrònic conté informació de caràcter confidencial dirigida
exclusivamen

Re: Reject client from domains without MX records

[li...@rhsoft.net]

Am 27.03.2014 18:52, schrieb Pau Peris:
> If i try to spoof email/sender address through Mozilla Thunderbird i get the 
> same error message as the one when
> relaying mailto:u...@example.com>>: Sender address 
> rejected: not owned by user us...@example.com
> ; So it looks like the issue only exists when 
> working locally like through the webmail
> solution

because "permit_mynetworks" does what it is supposed to do
if you don't have "mynetworks" configured the defaults are applied

[root@srv-rhsoft:~]$ postconf -d mynetworks
mynetworks = 127.0.0.0/8 62.178.103.0/24 192.168.2.0/24 192.168.10.0/24 
192.168.196.0/24 10.0.0.0/24

Re: transport_maps "loops back to myself"

[MV]

>Viktor Dukhovni wrote:
> Furthermore, because "*" is cached, you really don't want to use
> "*" at all for dynamic transport resolution.
Thanks for your input RE the caching of the special pattern "*" results.

> I answered your question upthread, use:
> sender_dependent_default_transport_maps
> For some reason you're still looking elsewhere...
I can't use sender_dependent_default_transport_maps because I don't
want to use sender-based static "routes". I'm looking for a "random"
or round-robin-ish split of smtp that provides consistent "helo ..
hostname .. ip .. reverse-dns-lookup"


Anyways, I've got the round-robin working now, using transport_maps
and this script https://gist.github.com/mvsantos/9813415
But I'm finding the solution very ugly. There must be a more elegant
way to do dynamic smtp deliveries...

$ postconf mail_version
mail_version = 2.11.0

# main.cf
transport_maps = tcp:127.0.0.1:

# master.cf
127.0.0.1:inetn   nn-0spawn
  user=nobody argv=/usr/local/sbin/postfix-smtp-roundrobin.pl

smtp1unix--n--smtp
-o myhostname=X.mydomain.tld
-o smtp_helo_name=X.mydomain.tld
-o smtp_bind_address=1.1.1.1
-o syslog_name=smtp-1

smtp2unix--n--smtp
-o myhostname=Y.mydomain.tld
-o smtp_helo_name=Y.mydomain.tld
-o smtp_bind_address=2.2.2.2
-o syslog_name=smtp-2
# End of master.cf


And for every mail sent or received I have 8 extra lines in my logs
(below, not in the correct order) and the time of processing has
increased a bit - not because of the extra logging, but because of the
transport_maps.

Let's see how it performs under load tomorrow, when I make it live...

smtp-roundrobin[1234]: Using: 'smtp2:' transport service. Query: get *
smtp-roundrobin[1234]: Using: 'smtp1:' transport service. Query: get *
smtp-roundrobin[1234]: Using: 'smtp2:' transport service. Query: get
b...@foreign.tld
smtp-roundrobin[1234]: Using: 'smtp1:' transport service. Query: get
f...@mydomain.tld
postfix/qmgr[4567]: smtp1:
default_destination_concurrency_positive_feedback feedback type 0
value at 5: 1
postfix/qmgr[4567]: smtp1:
default_destination_concurrency_negative_feedback feedback type 0
value at 5: 1
postfix/qmgr[4567]: smtp2:
default_destination_concurrency_positive_feedback feedback type 0
value at 5: 1
postfix/qmgr[4567]: smtp2:
default_destination_concurrency_negative_feedback feedback type 0
value at 5: 1

Re: Reject client from domains without MX records

[Robert Schetterer]

Am 27.03.2014 18:52, schrieb Pau Peris:
> If i try to spoof email/sender address through Mozilla Thunderbird i get
> the same error message as the one when relaying  >: Sender address rejected: not owned by user
> us...@example.com ; So it looks like the issue
> only exists when working locally like through the webmail solution.


configure your webmail to use smtp not sendmail binary ( as default in
most webmail )


Best Regards
MfG Robert Schetterer

-- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Franziskanerstraße 15, 81669 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: transport_maps "loops back to myself"

[Wietse Venema]

MV:
> I don't want to use sender-based static "routes". I'm looking for
> a "random" or round-robin-ish split of smtp that provides consistent
> "helo ..  hostname .. ip .. reverse-dns-lookup"

What is the legitimate use case for this kind of policy evasion?

Wietse

Re: Reject client from domains without MX records

[Pau Peris]

Hi,

i didn't configure mynetworks because i mynetworks_style is set to host. I
thought it was right thing to do to fit my needs which obviously looks like
not. Could you please exaplain me why is it wrong? I think i'm not fully
understanding why permit_mynetworks is wrong there.

Robert, i'm using Roundcube already configured to connect to smtp and not
as sendmail. Thanks for your tip.

Thanks again,



On Thu, Mar 27, 2014 at 7:32 PM, Robert Schetterer  wrote:

> Am 27.03.2014 18:52, schrieb Pau Peris:
> > If i try to spoof email/sender address through Mozilla Thunderbird i get
> > the same error message as the one when relaying  > >: Sender address rejected: not owned by user
> > us...@example.com ; So it looks like the issue
> > only exists when working locally like through the webmail solution.
>
>
> configure your webmail to use smtp not sendmail binary ( as default in
> most webmail )
>
>
> Best Regards
> MfG Robert Schetterer
>
> --
> [*] sys4 AG
>
> http://sys4.de, +49 (89) 30 90 46 64
> Franziskanerstraße 15, 81669 München
>
> Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
> Vorstand: Patrick Ben Koetter, Marc Schiffbauer
> Aufsichtsratsvorsitzender: Florian Kirstein
>



-- 
*Pau Peris Rodriguez*
*Chief Executive Officer (CEO)*
Tel: 669650292
C/Balmes 211, Principal Segunda
Barcelona 08006
http://www.webeloping.es

Aquest correu electrònic conté informació de caràcter confidencial dirigida
exclusivament al seu/s destinatari/s en còpia present. Tant mateix, queda
prohibida la seva divulgació, copia o distribució a tercers sense prèvia
autorització escrita per part de Pau Peris Rodriguez. En cas d'haver rebut
aquesta informació per error, es demana que es notifiqui
immediatament d'aquesta circumstancia mitjançant la direcció electrònica
del emissor.

Re: Reject client from domains without MX records

[li...@rhsoft.net]

can you please stop top-posting and using HTML on lists?
what is bad with HTML? look at the quote below after convert you message to 
plain

Am 27.03.2014 19:53, schrieb Pau Peris:
> i didn't configure mynetworks because i mynetworks_style is set to host. I 
> thought 
> it was right thing to do to fit my needs which obviously looks like not. 
> Could you 
> please exaplain me why is it wrong? 

why should it be right?

if you don't want to skip a restriction because the machine is
in "mynetworks" just don't put "permit_networks" before the
restriction or don't put the machine in question in "mynetworks"

i know nobody who changed "mynetworks_style" and i know a lot of admins

> On Thu, Mar 27, 2014 at 7:32 PM, Robert Schetterer  > wrote:
> 
> Am 27.03.2014 18 :52, schrieb Pau Peris:
> > If i try to spoof email/sender address through Mozilla Thunderbird i get
> > the same error message as the one when relaying  
> > >>: Sender address 
> rejected: not owned by user
> > us...@example.com   >; So it
> looks like the issue
> > only exists when working locally like through the webmail solution.
> 
> 
> configure your webmail to use smtp not sendmail binary ( as default in
> most webmail )

Re: Reject client from domains without MX records

[Pau Peris]

Hi,

i understand now the mistake. I'm reviewing the whole restrictions lot to
fix permit_mynetworks where it is needed.

I'm looking at Postfix site - http://postfix.org/postconf.5.html - for a
way to create exceptions as i would like some users like root to be able to
spoof their from address but i'm not able to find the right directive.
Would you dare pointing me to the right one?

Thank you so much. I rally appreciate your help




On Thu, Mar 27, 2014 at 7:53 PM, Pau Peris  wrote:

> Hi,
>
> i didn't configure mynetworks because i mynetworks_style is set to host. I
> thought it was right thing to do to fit my needs which obviously looks like
> not. Could you please exaplain me why is it wrong? I think i'm not fully
> understanding why permit_mynetworks is wrong there.
>
> Robert, i'm using Roundcube already configured to connect to smtp and not
> as sendmail. Thanks for your tip.
>
> Thanks again,
>
>
>
> On Thu, Mar 27, 2014 at 7:32 PM, Robert Schetterer  wrote:
>
>> Am 27.03.2014 18:52, schrieb Pau Peris:
>> > If i try to spoof email/sender address through Mozilla Thunderbird i get
>> > the same error message as the one when relaying > > >: Sender address rejected: not owned by user
>> > us...@example.com ; So it looks like the
>> issue
>> > only exists when working locally like through the webmail solution.
>>
>>
>> configure your webmail to use smtp not sendmail binary ( as default in
>> most webmail )
>>
>>
>> Best Regards
>> MfG Robert Schetterer
>>
>> --
>> [*] sys4 AG
>>
>> http://sys4.de, +49 (89) 30 90 46 64
>> Franziskanerstraße 15, 81669 München
>>
>> Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
>> Vorstand: Patrick Ben Koetter, Marc Schiffbauer
>> Aufsichtsratsvorsitzender: Florian Kirstein
>
>

Re: transport_maps "loops back to myself"

[Viktor Dukhovni]

On Thu, Mar 27, 2014 at 06:23:39PM +, MV wrote:

> >Viktor Dukhovni wrote:
> > Furthermore, because "*" is cached, you really don't want to use
> > "*" at all for dynamic transport resolution.
> Thanks for your input RE the caching of the special pattern "*" results.
> 
> > I answered your question upthread, use:
> > sender_dependent_default_transport_maps
> > For some reason you're still looking elsewhere...
>
> I can't use sender_dependent_default_transport_maps because I don't
> want to use sender-based static "routes". I'm looking for a "random"
> or round-robin-ish split of smtp that provides consistent "helo ..
> hostname .. ip .. reverse-dns-lookup"

Of course you can.  You're just not listening carefully.  Your
sender dependent maps would actually largely ignore the sender,
and just provide a round-robin response.  The important part is
that this mechanism returns a "default_transport" which never
overrides local or other more specific transport information.

This mechanism (being a lookup on the sender, which is a message,
not recipient property) can help avoid unnecessarily splitting of
the envelope for multi-recipient mail.  You should try to send all
the recipients of a message to the same default transport, therefore
you should have an modestly sized LRU cache within the round-robin
process that returns a cached answer for a cached sender, but
returns and caches a random answer for a new sender.

If many messages come predominantly from a single sender and (since
your traffic is likely single-recipient bulk mail, solicited or
otherwise) multi-recipient messages are rare, you may not need the
cache, since envelope splitting will not be useful, but the cache
might defeat the load-balancing you want.

> Anyways, I've got the round-robin working now, using transport_maps
> and this script https://gist.github.com/mvsantos/9813415
> But I'm finding the solution very ugly. There must be a more elegant
> way to do dynamic smtp deliveries...

Use socketmap (or the obsolete tcp table) with:

sender_dependent_default_transport_maps

Don't bother logging the queries except briefly if you're unsure
it is working.

-- 
Viktor.

Re: transport_maps "loops back to myself"

[MV]

> Wietse:
> What is the legitimate use case for this kind of policy evasion?

Just to be clear, I'm not a spammer, if anything, I couldn't be more
far from it.
I'm in the business of (strictly subscription-only) "monitoring
stuff". I mean, as soon as an event happens the subscribers who signed
up to that kind of event must be alerted immediately (99.% of the
times subscribers get a single email per day). But because we have
grown considerably recently, we needed extra outbound IPs because we
started to hit some ESP's limit of mail sent per hour from a single
source IP.

So I added an extra IP to the existing stack and used iptables to
split the outbound connections using the nat table.
But that created a problem because postfix would picks up the hostname
used in the helo (and other stuff???) from IP 1 and iptables would
route the connection through IP 2, so the client would see the message
headers like this one

Received: from .mydomain.tld (.mydomain.tld. [1.1.1.1])
by mta.foreign.tld with ESMTPS id abcdf
for 
(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Thu, 27 Mar 2014 

See how postfix helo was ".mydomain.tld" but the message actually
came from ".mydomain.tld".

And that simple header inconsistency bothers me (OCD)

So instead of splitting smtp using iptables I now use that script I
posted upthread, and the headers now look like this:

Received: from .mydomain.tld (.mydomain.tld. [1.1.1.1])
by mta.foreign.tld with ESMTPS id abcdf
for 
(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Thu, 27 Mar 2014 


Received: from .mydomain.tld (.mydomain.tld. [2.2.2.2])
by mta.foreign.tld with ESMTPS id abcdf
for 
(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Thu, 27 Mar 2014 


Is there a more elegant way achieve this?

Re: transport_maps "loops back to myself"

[MV]

Viktor Dukhovni:
> Of course you can.  You're just not listening carefully.  Your
I'm failing to grasp the concept and can't find any working examples online...
Finding this thread
http://thread.gmane.org/gmane.mail.postfix.user/203958 has helped a
bit..

> sender dependent maps would actually largely ignore the sender,
But how to I define the sender (map), if that's not asking too much,
could you please provide me with an example file?

> and just provide a round-robin response.  The important part is
> that this mechanism returns a "default_transport" which never
> overrides local or other more specific transport information.
> ...
> ... can help avoid unnecessarily splitting of
> the envelope for multi-recipient mail.  You should try to send all
And therefore would cut the overhead I currently have, right?

> the cache might defeat the load-balancing you want.
yep!

> Use socketmap (or the obsolete tcp table) with:
> sender_dependent_default_transport_maps
(mental note: this surely is the right way to do it, not the way I've done it.)

> Don't bother logging the queries except briefly if you're unsure
> it is working.
I'm just logging while debugging..


Marcus

Re: Reject client from domains without MX records

[li...@rhsoft.net]

PLEASE LEARN TO USE YOUR MAIL-CLIENT AND HOW TO QUOTE

* do not top post
* do not post HTML
* do not reply only to your own questions while you refer to answers
* if you continue that way of posting i just ignore you

this is a completly unreadable thread in the meanwhile
that below is hardly a response to my last message
__

back to topic:

* why would you like to spoof root?
* mails of cronjobs and such things are using the sendmail binary
* the sendmail binary has *no relevance* to SMTP restrictions because it is not 
SMTP

Am 27.03.2014 20:04, schrieb Pau Peris:
> i understand now the mistake. I'm reviewing the whole restrictions lot to fix 
> permit_mynetworks where it is needed.
> 
> I'm looking at Postfix site - http://postfix.org/postconf.5.html - for a way 
> to create exceptions as i would like
> some users like root to be able to spoof their from address but i'm not able 
> to find the right directive. Would you
> dare pointing me to the right one?
> 
> Thank you so much. I rally appreciate your help
> 
> 
> 
> 
> On Thu, Mar 27, 2014 at 7:53 PM, Pau Peris  > wrote:
> 
> Hi,
> 
> i didn't configure mynetworks because i mynetworks_style is set to host. 
> I thought it was right thing to do to
> fit my needs which obviously looks like not. Could you please exaplain me 
> why is it wrong? I think i'm not
> fully understanding why permit_mynetworks is wrong there.
> 
> Robert, i'm using Roundcube already configured to connect to smtp and not 
> as sendmail. Thanks for your tip.
> 
> Thanks again,
> 
> 
> 
> On Thu, Mar 27, 2014 at 7:32 PM, Robert Schetterer  > wrote:
> 
> Am 27.03.2014 18 :52, schrieb Pau Peris:
> > If i try to spoof email/sender address through Mozilla Thunderbird 
> i get
> > the same error message as the one when relaying  
> > >>: Sender 
> address rejected: not owned by user
> > us...@example.com  
> >; So it
> looks like the issue
> > only exists when working locally like through the webmail solution.
> 
> 
> configure your webmail to use smtp not sendmail binary ( as default in
> most webmail )

Re: transport_maps "loops back to myself"

[Viktor Dukhovni]

On Thu, Mar 27, 2014 at 07:44:46PM +, MV wrote:

> > sender dependent maps would actually largely ignore the sender,
>
> But how to I define the sender (map), if that's not asking too much,
> could you please provide me with an example file?

It is a program!  Not a fixed mapping.  It receives a sender address,
and replies (with a possibly cached per-sender) answer which is
computed on a mostly-round-robin basis.

> > and just provide a round-robin response.  The important part is
> > that this mechanism returns a "default_transport" which never
> > overrides local or other more specific transport information.
> > ...
> > ... can help avoid unnecessarily splitting of
> > the envelope for multi-recipient mail.  You should try to send all
>
> And therefore would cut the overhead I currently have, right?

Don't know what overhead you have in mind.  Transport lookups happen
in many places in Postfix.  Your transport switch needs to be fast,
(no verbose logging, ...) the rest is irrelevant.

> > the cache might defeat the load-balancing you want.
>
> yep!

Or it might not.  Do you send a flood of separate messages each
from the same sender?  If not the cache will help with multi-recipient
mail.  If all mail is single-recipient, you don't need a cache.

-- 
Viktor.

Re: transport_maps "loops back to myself"

[MV]

Viktor Dukhovni wrote:
> It is a program!  Not a fixed mapping.  It receives a sender address,
> and replies (with a possibly cached per-sender) answer which is
> computed on a mostly-round-robin basis.
If that's not asking too much, could you please provide me with a
practical example or point me to where I could to find one?

> Don't know what overhead you have in mind.
The overhead caused by my crappy perl script and its IO ops... but
this is irrelevant right now.

> Do you send a flood of separate messages each from the same sender?
By sender, do you mean email address or just $mydomain ?
If you mean sender=f...@mydomain.tld, then yes, most of the mail sent
comes from a single email account and is sent to a great number of
indivual recipients.


  Marcus

Re: transport_maps "loops back to myself"

[Wietse Venema]

MV:
> > Wietse:
> > What is the legitimate use case for this kind of policy evasion?
> 
> Just to be clear, I'm not a spammer, if anything, I couldn't be more
> far from it.
> I'm in the business of (strictly subscription-only) "monitoring
> stuff". I mean, as soon as an event happens the subscribers who signed
> up to that kind of event must be alerted immediately (99.% of the
> times subscribers get a single email per day). But because we have
> grown considerably recently, we needed extra outbound IPs because we
> started to hit some ESP's limit of mail sent per hour from a single
> source IP.

In that case, arrange for whitelisting like ever legitimate sender does.

Wietse

Can I reject when sender doesn't appear in from: header?

[Adam Moffett]

I'm seeing messages occasionally where the envelope sender is a 
verifiable address at someone else's domain, but the from: header 
contains some non-existent user @ our local domain.


Can postfix reject those messages?

Can postfix perform address verification on from: or reply-to: headers?

Attachment decoder (slightly O/T)

[Jeremy Bowen]

Just a quick request for advice on filtering incoming email.

About 12+ years ago on a system which has long since retired, I remember
having a problem with WINMAIL.DAT attachments in emails. The solution
used some combination of tools which, from memory, included
things like tnefclean and mmencode. It would process email on the
way into the server and sanitize it before delivering to the recipient's
inbox.

Some broken email clients can make a mess of attaching certain files
which other clients then cannot open. I was thinking of doing
something similar to the above (re-encode mime attachments) now but I'm
not sure what the best way of handling this is. Any advice appreciated.
Thanks.

Re: transport_maps "loops back to myself"

[Viktor Dukhovni]

On Thu, Mar 27, 2014 at 08:48:17PM +, MV wrote:

> > It is a program!  Not a fixed mapping.  It receives a sender address,
> > and replies (with a possibly cached per-sender) answer which is
> > computed on a mostly-round-robin basis.
>
> If that's not asking too much, could you please provide me with a
> practical example or point me to where I could to find one?

A small socketmap or tcp table service that ignores the lookup key
and returns the next element of a circular list of values with each
lookup is surely just a few lines of custom code.  As for how to
write a socketmap or tcp table driver in general, your Google skills
are likely not too dissimilar from mine.

In perl the core lookup function boils down to:

@choices = ( ... );
my $count = @choices;
my $next = 0;
sub lookup { return $choices[$next++ % $count]; }

which ignores the lookup key and returns the next choice.  You have
many choices of languages to choose from, and ways to run this as
a network or unix-domain socket service.

> > Don't know what overhead you have in mind.
>
> The overhead caused by my crappy perl script and its IO ops... but
> this is irrelevant right now.

A tcp or unix-domain socket request-reply round-trip should be
quite fast.

> > Do you send a flood of separate messages each from the same sender?
>
> By sender, do you mean email address or just $mydomain ?

Full envelope sender address.

> If you mean sender=f...@mydomain.tld, then yes, most of the mail sent
> comes from a single email account and is sent to a great number of
> individual recipients.

If you have the same sender for many concurrent messages (not just
multiple recipients of a single message), then you would not use
the proposed cache, making the code simpler.

-- 
Viktor.

Re: transport_maps "loops back to myself"

[MV]

Wietse wrote:
> In that case, arrange for whitelisting like ever legitimate sender does.

I do that for Gmail, Yahoo, Microsoft, AOL ..  and it works, so much
so that we have never been graylisted by any of those folks despite
the tens of thousands emails we send daily.
But I can't afford do that for the thousands of other ESPs that my clients use.
We actually stop emailing users after the second failure and let them
know about it upon login to the web dashboard.
Users normally contact their ESPs on their own and once sorted they
normally ask us to restore their alerts. And sometimes they just
create a new email account in a big free ESP .

Re: Attachment decoder (slightly O/T)

[Hannes Erven]

Hi Jeremy,


> I was thinking of doing something similar to the above (re-encode
> mime attachments) now but I'm not sure what the best way of handling
> this is.

I'm using the following setup to modify attachments from a specific 
sender only:


/etc/postfix/master.cf:
tiff2pdf unix  -   n   n   -   -   pipe
flags= user=nobody directory=/path/ argv=/path/tiff2pdf.pl 
${nexthop} ${sender} ${recipient}



/etc/postfix/tiff2pdf:
example.com FILTER tiff2pdf:


/etc/postfix/main.cf or master.cf:
smtpd_sender_restrictions=hash:/etc/postfix/tiff2pdf


The tiff2pdf.pl file reads the message from stdin:

my $parser = new MIME::Parser;
$msg = $parser->parse(\*STDIN) or die "FaxTIFF2PDF: parse failed\n";


and then does its magic iterating through the attachments, deciding what 
to do, de- and re-attaching them as needed.



Finally, it uses "use IPC::Open2;" to issue this command:

$pid = open2(\*CHLD_OUT, \*CHLD_IN, '/usr/sbin/sendmail', '-G', '-i', 
'-f', "$from", "$to");

$msg->print(\*CHLD_IN);
close(\*CHLD_IN);
waitpid( $pid, 0 );
my $child_exit_status = $? >> 8;

if ($child_exit_status ne 0){ die print "Error from sendmail: 
$child_exit_status"};




This may not be the most elegant way to do this, but it certainly works 
very well.



Best regards,

-hannes

Re: Reject client from domains without MX records

[Pau Peris]

Excuse me, i'll try to follow your rules. The HTML thing was due to the
reader, i think it took web URL and emails into HTML tags. Excuses.

Respect the exceptions list, you talk about cron emails using sendmail but
it is using aliases table specified in main.cf also uses an email rewriter
table specified in main.cf If possible would like to create an exception
table. The case is i would like aliases to be only used for recieving and
forwarding to real email boxes. I do not want to let users login through
aliases. Also i would like some users like root to rewrite its email.

Last, i think master.cf is overwriting some restrictions because when
emails first get smtp it gets rejected if login missmatch sender address,
then don't know why it is passed to amavis content filter when it really
should get rejected and after amavis injects the email again into smtp it
gets delivered. It's pretty weird, but i'm not able to find my mistake.

Thanks a lot!!
--

Sent from my Android mobile, excuse the brevity.
On Mar 27, 2014 9:17 PM, "li...@rhsoft.net"  wrote:

> PLEASE LEARN TO USE YOUR MAIL-CLIENT AND HOW TO QUOTE
>
> * do not top post
> * do not post HTML
> * do not reply only to your own questions while you refer to answers
> * if you continue that way of posting i just ignore you
>
> this is a completly unreadable thread in the meanwhile
> that below is hardly a response to my last message
> __
>
> back to topic:
>
> * why would you like to spoof root?
> * mails of cronjobs and such things are using the sendmail binary
> * the sendmail binary has *no relevance* to SMTP restrictions because it
> is not SMTP
>
> Am 27.03.2014 20:04, schrieb Pau Peris:
> > i understand now the mistake. I'm reviewing the whole restrictions lot
> to fix permit_mynetworks where it is needed.
> >
> > I'm looking at Postfix site - http://postfix.org/postconf.5.html - for
> a way to create exceptions as i would like
> > some users like root to be able to spoof their from address but i'm not
> able to find the right directive. Would you
> > dare pointing me to the right one?
> >
> > Thank you so much. I rally appreciate your help
> >
> >
> >
> >
> > On Thu, Mar 27, 2014 at 7:53 PM, Pau Peris  p...@webeloping.es>> wrote:
> >
> > Hi,
> >
> > i didn't configure mynetworks because i mynetworks_style is set to
> host. I thought it was right thing to do to
> > fit my needs which obviously looks like not. Could you please
> exaplain me why is it wrong? I think i'm not
> > fully understanding why permit_mynetworks is wrong there.
> >
> > Robert, i'm using Roundcube already configured to connect to smtp
> and not as sendmail. Thanks for your tip.
> >
> > Thanks again,
> >
> >
> >
> > On Thu, Mar 27, 2014 at 7:32 PM, Robert Schetterer  r...@sys4.de>> wrote:
> >
> > Am 27.03.2014 18 :52, schrieb Pau Peris:
> > > If i try to spoof email/sender address through Mozilla
> Thunderbird i get
> > > the same error message as the one when relaying <
> u...@example.com 
> > > >>: Sender
> address rejected: not owned by user
> > > us...@example.com   us...@example.com >; So it
> > looks like the issue
> > > only exists when working locally like through the webmail
> solution.
> >
> >
> > configure your webmail to use smtp not sendmail binary ( as
> default in
> > most webmail )
>