question concerning content filter and receive_override_options=no_address_mappings

[Peter Sørensen]

Hi

I have a policy server restricting access to specific lists. If a user is 
accepted the policy server return OK status
to postfix. The members on the list are found through virtual alias and gets 
expanded.

I would like to put a content filter after this ,  that will grab the orig_to 
address to do further handling on 
this mail.

I can't manage to make this work before the allias expanding.

I have following in master.cf:

mailstamp unix -   n   n   -  -   pipe
  -o receive_override_options=no_address_mappings
  flags=Rq user=mail   argv=/usr/local/lib/postfix/mailstamp.pl -f $sender -- 
$recipient

And made a tranport entry like:

mytestll...@yy.xx.dk mailstamp:


I then send a mail to mytestl...@yy.xx.dk but this does'nt activate the content 
filter probably
because the lists gets expanded and it's not acting on the orig_to address . I 
would expect
that the receive_override_options=no_address_mapping would avoid that.

Can I do this in another way ??

Best regards


Peter Sorensen/Univ Of Southern Denmark/Email: mas...@sdu.dk

 

Postfix Question

[Feel Zhou]

Hi, My friend


I got your email address from postmaster@postfix,org



I'm from China, Sorry about my English



I learning postfix for few month, and I think it is the best mail server.



But there is some problem that I can't solve it, can you help me?



For example: ServerA and ServerB , install postfix-2.9.3 all,



They have different IP address, at different place.



Sometimes, use ServerA, send email to hotmail (for example).



Maybe it was reject or defer  by hotmail, maybe not.



In the main.cf at ServerA,  set relayhost = ServerB, it working.



So the ServerA has nothing to do



And ServerB is so busy, because all mail use it to send outside



My purpose is :



Use ServerA, try it best, send email to hotmail,



if working, very good, if not (such as reject, defer ),  then give the
email to ServerB.



Do not use ServerB all the time.



Another way



ServerA must work harder, try the best to send email.



I don’t want ServerA bounce email, and don’t want defer email more than 2
minutes,



ServerB can do all things when ServerA can’t finish it’s job.



ServerB can’t send email or defer email more than 5 minutes, then bounce



How can I set conditions in the ServerA



Thank you very much



Tom

Re: Thunderbird and Postfix

[Benny Pedersen]

Den 2012-06-06 23:05, Nicolás skrev:


Jun  6 21:23:35 mail postfix/smtpd[13009]: 3035F1C:
client=unknown[192.168.0.10], sasl_method=PLAIN,
sasl_username=nico...@devels.es


if sasl username is auth'ed there is no way to make sure From: does 
match it, but it will still be password checked with the password in 
dovecot login right ?, only thing postfix can do more is to ask for the 
password if sender is local, mostly when sender and recipient is equal 
(spammers try this route)


From: is part of the body in mail sending so it can be filtered with 
header checks after sasl auth is passed :)


but this filter must not being apply to incomming emails that returns 
from maillists, so its a bit unsecure to make a header filter for this

Re: Thunderbird and Postfix

[Nicolás]

El 06/06/2012 22:25, Patrick Ben Koetter escribió:

* Nicolás:

I'm new to this list and the reason why I'm writing is because I
found out one thing I think is worrying enough to share it with you

I've got my Postfix configured with virtual users, integrated with
Dovecot. Everything's working fine, no (known) configuration issues.
I was mainly investigating on my Mozilla Thunderbird, concretely the
Identities option. I tried to add an 'identity' (with a fictional
login), just to try what would happen and surprisingly the mail was
sent out without any problem - using the configuration of the 'real'
account:

Jun  6 21:23:35 mail postfix/smtpd[13009]: 3035F1C:
client=unknown[192.168.0.10], sasl_method=PLAIN,
sasl_username=nico...@devels.es
Jun  6 21:23:35 mail postfix/cleanup[13017]: 3035F1C:
message-id=<4fcfbc49.60...@devels.es>
Jun  6 21:23:35 mail postfix/qmgr[1766]: 3035F1C:
from=, size=651, nrcpt=1 (queue active)
Jun  6 21:23:35 mail postfix/smtpd[13009]: disconnect from
unknown[192.168.0.10]
Jun  6 21:23:37 mail postfix/pickup[12624]: 28C801012C0: uid=5002
from=
Jun  6 21:23:37 mail postfix/cleanup[13017]: 28C801012C0:
message-id=<4fcfbc49.60...@devels.es>
Jun  6 21:23:37 mail postfix/pipe[13019]: 3035F1C:
to=, relay=spamassassin, delay=2.1,
delays=0.25/0.05/0/1.8, dsn=2.0.0, status=sent (delivered via
spamassassin service)
Jun  6 21:23:37 mail postfix/qmgr[1766]: 3035F1C: removed

My question is: How 'safe' is this? Is there any way to restrict
creating identities for users unless the administrator allows to do
so? I really would be worried if ANY user would create ANY
identities and use them the way he wants... Any ideas appreciated!

SASL in Postfix authenticates identities. It is up to Postfix to authorize a
known identity to do something. Currently Postfix  can do two things for
authenticated identities:

1. Permit identity to relay
2. Permit identity to use one or more envelope senders

You have only configured use case 1. Read into smtpd_sender_login_maps to
setup and configure use case 2 also.

p@rick





Thanks!

Nicolás


Thank you very much, Patrick.

Now it works the way I described :-))

Nicolás

Re: Thunderbird and Postfix

[Patrick Ben Koetter]

* Nicolás :
> I'm new to this list and the reason why I'm writing is because I
> found out one thing I think is worrying enough to share it with you
> 
> I've got my Postfix configured with virtual users, integrated with
> Dovecot. Everything's working fine, no (known) configuration issues.
> I was mainly investigating on my Mozilla Thunderbird, concretely the
> Identities option. I tried to add an 'identity' (with a fictional
> login), just to try what would happen and surprisingly the mail was
> sent out without any problem - using the configuration of the 'real'
> account:
> 
> Jun  6 21:23:35 mail postfix/smtpd[13009]: 3035F1C:
> client=unknown[192.168.0.10], sasl_method=PLAIN,
> sasl_username=nico...@devels.es
> Jun  6 21:23:35 mail postfix/cleanup[13017]: 3035F1C:
> message-id=<4fcfbc49.60...@devels.es>
> Jun  6 21:23:35 mail postfix/qmgr[1766]: 3035F1C:
> from=, size=651, nrcpt=1 (queue active)
> Jun  6 21:23:35 mail postfix/smtpd[13009]: disconnect from
> unknown[192.168.0.10]
> Jun  6 21:23:37 mail postfix/pickup[12624]: 28C801012C0: uid=5002
> from=
> Jun  6 21:23:37 mail postfix/cleanup[13017]: 28C801012C0:
> message-id=<4fcfbc49.60...@devels.es>
> Jun  6 21:23:37 mail postfix/pipe[13019]: 3035F1C:
> to=, relay=spamassassin, delay=2.1,
> delays=0.25/0.05/0/1.8, dsn=2.0.0, status=sent (delivered via
> spamassassin service)
> Jun  6 21:23:37 mail postfix/qmgr[1766]: 3035F1C: removed
> 
> My question is: How 'safe' is this? Is there any way to restrict
> creating identities for users unless the administrator allows to do
> so? I really would be worried if ANY user would create ANY
> identities and use them the way he wants... Any ideas appreciated!

SASL in Postfix authenticates identities. It is up to Postfix to authorize a
known identity to do something. Currently Postfix  can do two things for
authenticated identities:

1. Permit identity to relay
2. Permit identity to use one or more envelope senders

You have only configured use case 1. Read into smtpd_sender_login_maps to
setup and configure use case 2 also.

p@rick




> 
> Thanks!
> 
> Nicolás

-- 
All technical questions asked privately will be automatically answered on the
list and archived for public access unless privacy is explicitely required and
justified.

saslfinger (debugging SMTP AUTH):

Thunderbird and Postfix

[Nicolás]

Hi everyone!

I'm new to this list and the reason why I'm writing is because I found 
out one thing I think is worrying enough to share it with you


I've got my Postfix configured with virtual users, integrated with 
Dovecot. Everything's working fine, no (known) configuration issues. I 
was mainly investigating on my Mozilla Thunderbird, concretely the 
Identities option. I tried to add an 'identity' (with a fictional 
login), just to try what would happen and surprisingly the mail was sent 
out without any problem - using the configuration of the 'real' account:


Jun  6 21:23:35 mail postfix/smtpd[13009]: 3035F1C: 
client=unknown[192.168.0.10], sasl_method=PLAIN, 
sasl_username=nico...@devels.es
Jun  6 21:23:35 mail postfix/cleanup[13017]: 3035F1C: 
message-id=<4fcfbc49.60...@devels.es>
Jun  6 21:23:35 mail postfix/qmgr[1766]: 3035F1C: 
from=, size=651, nrcpt=1 (queue active)
Jun  6 21:23:35 mail postfix/smtpd[13009]: disconnect from 
unknown[192.168.0.10]
Jun  6 21:23:37 mail postfix/pickup[12624]: 28C801012C0: uid=5002 
from=
Jun  6 21:23:37 mail postfix/cleanup[13017]: 28C801012C0: 
message-id=<4fcfbc49.60...@devels.es>
Jun  6 21:23:37 mail postfix/pipe[13019]: 3035F1C: 
to=, relay=spamassassin, delay=2.1, 
delays=0.25/0.05/0/1.8, dsn=2.0.0, status=sent (delivered via 
spamassassin service)

Jun  6 21:23:37 mail postfix/qmgr[1766]: 3035F1C: removed

My question is: How 'safe' is this? Is there any way to restrict 
creating identities for users unless the administrator allows to do so? 
I really would be worried if ANY user would create ANY identities and 
use them the way he wants... Any ideas appreciated!


Thanks!

Nicolás

Re: Disable outbound smtp pipelining?

[k...@rice.edu]

On Wed, Jun 06, 2012 at 03:24:41PM -0400, Wietse Venema wrote:
> Curtis:
> > Yeah, I figured it would be a pretty significant slow down for hosts 
> > that support it... I just wasn't sure what percentage of hosts support 
> > pipelining.  If only 10% of hosts were using it in the first place, the 
> > 40% extra delivery time lost on those hosts might be managable... but, 
> > if you're saying that the majority of hosts do have pipelining enabled 
> > (it makes sense that they would), then a 40% slow down would probably be 
> > too expensive.
> 
> I have no statistics for ESMTP PIPELINING deployment. Many major
> MTA implementation support this, but unfortunately some "security"
> "firewall" implementors still make basic mistakes, and that is
> probably what we are looking at.
> 
>   Wietse
> 
Hi Wietse,

I really like your idea about a time-based fallback to a no-pipelining
send similar to the Cisco PIX work-around.

Regards,
Ken

Re: client-side authentication broken?

[Toni Mueller]

Hi,

On Wed, Jun 06, 2012 at 03:43:21PM +0200, DTNX Postmaster wrote:
> On Jun 6, 2012, at 13:16, Toni Mueller wrote:
> > In main.cf, this looks like follows:
> > 
> > mtp_sasl_auth_enable = yes
> 
> Is the above a typo in your configuration, or a copy-paste error? 
> Because it should have an 's' in front of it?

thanks for pointing this out. It's a copy&paste error. The file really
has the 's' where it belongs.


Kind regards,
--Toni++

Re: Disable outbound smtp pipelining?

[Wietse Venema]

Curtis:
> Yeah, I figured it would be a pretty significant slow down for hosts 
> that support it... I just wasn't sure what percentage of hosts support 
> pipelining.  If only 10% of hosts were using it in the first place, the 
> 40% extra delivery time lost on those hosts might be managable... but, 
> if you're saying that the majority of hosts do have pipelining enabled 
> (it makes sense that they would), then a 40% slow down would probably be 
> too expensive.

I have no statistics for ESMTP PIPELINING deployment. Many major
MTA implementation support this, but unfortunately some "security"
"firewall" implementors still make basic mistakes, and that is
probably what we are looking at.

Wietse

Re: Disable outbound smtp pipelining?

[Benny Pedersen]

Den 2012-06-06 05:46, Curtis skrev:

[snip]

I better stop asking questions now since I might be getting ahead of
my self if my assumption about 
smtpd_discard_ehlo_keyword_address_maps

does not actually apply to outbound email...


back to basic:

smtpd_* is incomming
smtp_* is outgoing

Re: mynetworks support for ipv6 link local (fe80) hosts

[Wietse Venema]

Derek Atkins:
> Wietse Venema  writes:
> 
> > For the record: mynetworks has always supported net/mask notation.
> 
> Of course, but that wasn't what I was talking about, and it never was.
> I was talking about "permit_mynetworks" working properly with an ipv6
> link local address specified in mynetworks, and *that* wasn't working
> due the extraneous "%eth0" in the address from the Linux "AddrToString"
> functions.

You stated that (permit)mynetworks should support link-local suffixes
(they never did, and to this date thet don't). Instead, when I
learned that such suffixes crept into Postfix via non-Postfix library
routines, I added code to strip them.

Wietse

Re: Sending mail to custom transport and second server

[Wietse Venema]

Jeroen Geilman:
>  @example.netcatch...@second.postfix.box
> 
> Depending on your specific setup, there may be much better solutions,
> but this is what you asked for verbatim.

Wiebe Cazemier:
> Actually, this is not really what I meant. This BCCs everything
> to one e-mail address. What I would like, is to have a transport
> with two nexthops, so to speak. I need the primary server to deliver
> to its zarafa transport as well as relay to the secondary server.
> The secondary server then knows to which address it was sent and
> places the X-Original-To and Delivered-To.

That functionality is provided by the pcre-based sender_bcc_maps
solution - it makes one "secondary" delivery for each recipient.
I guess by now we have covered all options available in existing
Postfix releases.

Wietse

Re: Different smtpd_client_restrictions policies for different recipient domains ?

[Dennis Guhl]

On Wed, Jun 06, 2012 at 09:15:55AM -0600, David Boreham wrote:

[How to apply a restriction at some connections only?]

> What's the best way to implement this ? I think restriction classes
> are the way to go , but I'm not 100% sure.

They are exactly the way to go.

See here: http://www.postfix.org/RESTRICTION_CLASS_README.html

Dennis

Different smtpd_client_restrictions policies for different recipient domains ?

[David Boreham]

Scratching my head on whether this is possible:

I suppose I want to do something like a database 'join' in my Postfix setup.
e.g. enforce this check_client_access rule if and only if the recipient 
is in one of the following domains...


This has arisen because we use MXLogic to filter inbound email, but only 
for a subset of the domains we're hosting.
MXLogic works by pointing the domain MX record at their servers, which 
then relay/proxy to our Postfix.
Spammers figure out how to bypass the filtering by delivering directly 
to the Postfix server (presumably
they spot that mail.foo.com points to a machine that accepts connections 
on port 25 and delivery for foo.com).
The way to thwart this filter bypass traffic is to deny local delivery 
to clients that are not on MXLogic's
subnets. This is easy to do with a check_client_access directive and a 
cidr table.


But if there are some domains hosted that are not subject to MXLogic 
filtering (their spam filtering
is done MUA-side), a global check_client_access rule won't work because 
it will deny local delivery to

legitimate MTA traffic for those domains.

Hence the desire to make the subnet restriction domain-specific.

What's the best way to implement this ? I think restriction classes  are 
the way to go , but I'm not 100% sure.

Any pointers appreciated.

Thanks.

Re: Disable outbound smtp pipelining?

[Curtis]

On 6/6/2012 8:45 AM, Wietse Venema wrote:

Curtis:

smtp_discard_ehlo_keywords = pipelining,silent-discard

(Again, this time without the d.)  Aside from a little extra bandwidth,
would this cause outbound deliveries to go horrendously slower on a busy
mail server?

The issue is NOT bandwidth (i.e. the width of a pipe). It's latency


Yeah, I realized that the bandwidth impact would be minimal. (Someone 
else noted in another thread a slight increase of bandwidth due to the 
extra TCP round-trips.)



(i.e.  the distance between pipe endpoints). You can increase the
former, but you can't break the speed-of-light limit.

Pipelining reduces the number of TCP round-trip times, At a minimum
there will be 5 round-trip times (SYN-SYNACK, ACK-220, EHLO-EHLOREPLY,
DATA-DATAREPLY, ENDOFDATA-ENDOFDATAREPLY; the SMTP client does not
wait for final handshake completion). Disabling pipelining adds one
round-trip time for each MAIL FROM and for each RCPT TO command,
from 5 to 7 or more. Your SMTP server may spend 40% more time
delivering mail, depending on the number of messages per destination
(which reduces impact of DNS lookups), and on the number of recipients
per message.


Yeah, I figured it would be a pretty significant slow down for hosts 
that support it... I just wasn't sure what percentage of hosts support 
pipelining.  If only 10% of hosts were using it in the first place, the 
40% extra delivery time lost on those hosts might be managable... but, 
if you're saying that the majority of hosts do have pipelining enabled 
(it makes sense that they would), then a 40% slow down would probably be 
too expensive.




Postfix has bug workarounds for CISCO PIX that are enabled automatically
when mail has been queued for 500s ore more. Maybe some of the
optimizations such as command pipelining could also be made
time-dependent.


That would be awesome.  I will stay tuned for that.  In the mean time, 
it sounds like we'll have to stick with the 
smtp_discard_ehlo_keyword_address_maps solution.  We'll just have to set 
up something to monitor the logs and automatically add problem hosts.  I 
love how there's almost always multiple ways to solve a problem with 
Postfix.


Postfix rocks! :-)

Curtis




Wietse

Re: Disable outbound smtp pipelining?

[Wietse Venema]

Curtis:
> smtp_discard_ehlo_keywords = pipelining,silent-discard
> 
> (Again, this time without the d.)  Aside from a little extra bandwidth, 
> would this cause outbound deliveries to go horrendously slower on a busy 
> mail server?

The issue is NOT bandwidth (i.e. the width of a pipe). It's latency
(i.e.  the distance between pipe endpoints). You can increase the
former, but you can't break the speed-of-light limit.

Pipelining reduces the number of TCP round-trip times, At a minimum
there will be 5 round-trip times (SYN-SYNACK, ACK-220, EHLO-EHLOREPLY,
DATA-DATAREPLY, ENDOFDATA-ENDOFDATAREPLY; the SMTP client does not
wait for final handshake completion). Disabling pipelining adds one
round-trip time for each MAIL FROM and for each RCPT TO command,
from 5 to 7 or more. Your SMTP server may spend 40% more time
delivering mail, depending on the number of messages per destination
(which reduces impact of DNS lookups), and on the number of recipients
per message.

Postfix has bug workarounds for CISCO PIX that are enabled automatically
when mail has been queued for 500s ore more. Maybe some of the
optimizations such as command pipelining could also be made
time-dependent.

Wietse

Re: Disable outbound smtp pipelining?

[Curtis]

On 6/5/2012 10:44 PM, Viktor Dukhovni wrote:

On Tue, Jun 05, 2012 at 09:46:16PM -0600, Curtis wrote:


However, I'm not sure I fully understand why this fixes the problem
for outbound email.  On outbound email, Postfix is acting as the
client and therefore one might think that
smtpd_discard_ehlo_keyword_address_maps would not have any effect,
since this setting is supposed to suppress EHLO keywords in response
to a client.

Correct the Postfix SMTP server-specific setting has no effect on
Postfix SMTP client behaviour.


Does smtpd_discard_ehlo_keyword_address_maps also
ignore EHLO keyword responses it receives on outbound connections?

NO.


I'm guessing so, because unless something else changed, the solution
worked.

The observations are erroneous.


Actually it was my reference to smtpd_discard_ehlo_keyword_address_maps 
that was erroneous.  (Thanks Ralf for pointing out my error!)  The 
actual parameter name referenced in the solution that Wiestse provided 
in the thread I referenced was smtp_discard_ehlo_keyword_address_maps 
(no d).


The fix I implemented was actually 
smtp_discard_ehlo_keyword_address_maps (no d) as well.   When I went to 
look up the parameter in the documentation to see why it worked, I got 
my parameter names mixed up, which is why I was confused as to why the 
solution worked.Now that I'm looking at the right parameter name in 
the documentation, it is clear that 
smtp_discard_ehlo_keyword_address_maps does the job for outbound 
connections.


I don't get into the Postfix configs often enough, as I had forgotten 
that there were several parameters that were so similarly named (which 
is actually a good thing once you understand the naming scheme).





Does anyone have any
experience with just turning it off completely for all hosts? Which,
I suppose would be done like this:

I've never had to work-around remote PIPELINING issues at remote
sites and I ran a fairly busy MTA plant delivering ~2M messages
per day. Some people have reported a small number of sites for
which they needed work-arounds, but you should not be seeing
a lot of remote peers with the issue unless there is a problem
with a firewall at your site. Fix that.



Our mail servers are busy here too.  I think you'll start to see some 
issues as well, as Wietse clearly shows that there are some broken 
servers out there:


http://www.mail-archive.com/postfix-users@postfix.org/msg44135.html

The one referenced in the above thread is a Lunarpages server, which is 
where we first ran into the same problem, and now we've run into the 
issue with a Bluehost server as well.  Bluehost claims to host millions 
of domains and I suppose Lunarpages isn't that far behind. I suspect 
they each have several hundred mail servers between them that would all 
need to be added to the exceptions list that Wietse recommended.  I 
think these hosts broke something in May as we've just started get 
complaints of intermittent issues delivering to them.


So again, I'll ask if anyone out there has resorted to turning off 
pipelining on outbound connections? ...


smtp_discard_ehlo_keywords = pipelining,silent-discard

(Again, this time without the d.)  Aside from a little extra bandwidth, 
would this cause outbound deliveries to go horrendously slower on a busy 
mail server?


Thanks,

Curtis

Re: client-side authentication broken?

[DTNX Postmaster]

On Jun 6, 2012, at 13:16, Toni Mueller wrote:

> I recently upgraded a machine from Postfix 2.8 to 2.9. The machine uses,
> amongst other things, a custom transport to facilitate masking outgoing
> email addresses and sending with SMTP-AUTH.
> 
> In main.cf, this looks like follows:
> 
> mtp_sasl_auth_enable = yes

Is the above a typo in your configuration, or a copy-paste error? 
Because it should have an 's' in front of it?

Cya,
Jona

--

> smtp_sender_dependent_authentication = yes
> smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
> smtp_tls_security_level = encrypt
> smtp_sasl_security_options = noanonymous
> 
> In master.cf I now have this in attempt to fix this problem:
> 
> globalout  unix  -   -   -   -   -   smtp -v -v
>-o smtp_generic_maps=hash:/etc/postfix/global_rewrite
>-o smtp_sasl_auth_enable=yes
>-o smtp_sender_dependent_authentication=yes
>-o smtp_sasl_password_maps=hash:/etc/postfix/sasl_passwd
>-o smtp_tls_security_level=encrypt
>-o smtp_sasl_security_options=noanonymous
> 
> 
> where "globalout" is the mail transport used for off-site mails.
> 
> 
> For some reason, that stopped working: I can't see an authentication
> attempt on the server side, only a plain TLS connection and then an
> attempt to push out the email.
> 
> I'd really like to get this back into working order... suggestions
> are welcome!
> 
> 
> TIA!
> 
> 
> 
> Kind regards,
> --Toni++

Re: Sending mail to custom transport and second server

[Wiebe Cazemier]

- Original Message -
> From: "Jeroen Geilman" 
> To: postfix-users@postfix.org
> Sent: Tuesday, 5 June, 2012 7:51:47 PM
> Subject: Re: Sending mail to custom transport and second server
>
> 
> recipient_bcc_maps = hash:/etc/postfix/backup_domains, with the
> following content:
> 
>  @example.netcatch...@second.postfix.box
> 
> Depending on your specific setup, there may be much better solutions,
> but this is what you asked for verbatim.

Actually, this is not really what I meant. This BCCs everything to one e-mail 
address. What I would like, is to have a transport with two nexthops, so to 
speak. I need the primary server to deliver to its zarafa transport as well as 
relay to the secondary server. The secondary server then knows to which address 
it was sent and places the X-Original-To and Delivered-To.

client-side authentication broken?

[Toni Mueller]

Hi,

I recently upgraded a machine from Postfix 2.8 to 2.9. The machine uses,
amongst other things, a custom transport to facilitate masking outgoing
email addresses and sending with SMTP-AUTH.

In main.cf, this looks like follows:

mtp_sasl_auth_enable = yes
smtp_sender_dependent_authentication = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_tls_security_level = encrypt
smtp_sasl_security_options = noanonymous

In master.cf I now have this in attempt to fix this problem:

globalout  unix  -   -   -   -   -   smtp -v -v
-o smtp_generic_maps=hash:/etc/postfix/global_rewrite
-o smtp_sasl_auth_enable=yes
-o smtp_sender_dependent_authentication=yes
-o smtp_sasl_password_maps=hash:/etc/postfix/sasl_passwd
-o smtp_tls_security_level=encrypt
-o smtp_sasl_security_options=noanonymous


where "globalout" is the mail transport used for off-site mails.


For some reason, that stopped working: I can't see an authentication
attempt on the server side, only a plain TLS connection and then an
attempt to push out the email.

I'd really like to get this back into working order... suggestions
are welcome!


TIA!



Kind regards,
--Toni++

Re: Disable outbound smtp pipelining?

[Ralf Hildebrandt]

* Curtis :
> It seems we are running into an increased number of hosts that have
> broken smtp pipelining.  We are able to resolve delivery issues to
> these hosts using the solution that Wieste recommended a couple weeks
> ago:
> 
> http://www.mail-archive.com/postfix-users@postfix.org/msg44135.html
>
> However, I'm not sure I fully understand why this fixes the problem
> for outbound email.  On outbound email, Postfix is acting as the
> client and therefore one might think that
> smtpd_discard_ehlo_keyword_address_maps would not have any affect,

This links lists smtp_discard_ehlo_keyword_address_maps (no d)
not smtpd_discard_ehlo_keyword_address_maps

-- 
Ralf Hildebrandt
  Geschäftsbereich IT | Abteilung Netzwerk
  Charité - Universitätsmedizin Berlin
  Campus Benjamin Franklin
  Hindenburgdamm 30 | D-12203 Berlin
  Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
  ralf.hildebra...@charite.de | http://www.charite.de