Re: Enabled SMTP AUTH but mails from external networks still being rejected

[Benny Pedersen]

Den 2012-03-28 15:31, Phill Edwards skrev:


Mar 29 00:04:33 zrf postfix/smtpd[624]: NOQUEUE: reject: RCPT from
unknown[xx.xxx.180.193]: 554 5.7.1 : Client
host rejected: Access denied; from=



smtpd_client_restrictions = permit_mynetworks, reject


missing permit_sasl_authenticated

postfix do as you say :)

Re: Postfix cannot send mails when Mailscanner is added

[Brian Evans - Postfix List]

On 4/3/2012 9:32 AM, Kizito Thomas wrote:
> Dear good people,
> I am trying out Mailscanner for the first time in my life, I have this
> test postfix server that has been working properly until when I added
> a line:
> /**/
>

I highly recommend to use amavisd-new instead of Mailscanner.
The former uses either the milter, before-queue or after-queue methods
which exist in Postfix.
The latter uses an unsupported direct queue manipulation which is not
guaranteed to work correctly in Postfix.

Brian

TLS Emails

[Mark Pote]

Hi all,

I have a Centos, Postfix, Amavisd, Spamassassin, MySQL setup and clean mail for 
quite a few domains.

One of these domains in particular is a remote site with their own Exchange 
2007 server and they have asked me to allow TLS emails through, HSBC Bank is 
asking for this.

I have looked around on how this works but so far I haven't found a clear 
explanation. I know that I need to setup postfix to receive the TLS emails, 
which shouldn't be a problem, and we need a verified certificate. I have also 
found that we then need to set up SASL to forward the mails onto the companies 
own email server and this is where I'm starting to get confused.

Does anyone know how postfix/amavisd/spamassassin handles this and if it is at 
all possible? Do TLS emails bypass the spam checking or do I setup rules to 
lower the score if they are from this source?

Any help would be appriciated.


Mark

Re: TLS Emails

[/dev/rob0]

On Tue, Apr 03, 2012 at 02:02:37PM +, Mark Pote wrote:
> I have a Centos, Postfix, Amavisd, Spamassassin, MySQL setup and 
> clean mail for quite a few domains.
> 
> One of these domains in particular is a remote site with their
> own Exchange 2007 server and they have asked me to allow TLS
> emails through, HSBC Bank is asking for this.

I don't think the request is reasonable, but it is easy to do. A 
restriction class for this recipient domain, checked after 
reject_unauth_destination, which calls permit_tls_all_clientcerts.

http://www.postfix.org/RESTRICTION_CLASS_README.html
http://www.postfix.org/TLS_README.html#server_access
http://www.postfix.org/postconf.5.html#check_recipient_access
http://www.postfix.org/postconf.5.html#permit_tls_all_clientcerts

> I have looked around on how this works but so far I haven't found a 
> clear explanation. I know that I need to setup postfix to receive 
> the TLS emails, which shouldn't be a problem, and we need a 
> verified certificate. I have also found that we then need to set up 
> SASL to forward the mails onto the companies own email server and 
> this is where I'm starting to get confused.

How were you forwarding these mails before? Why are they requiring 
you to authenticate? Being enamoured with TLS, perhaps they would 
like to set up TLS certificate authentication. Anyway, either is 
documented:

SASL: http://www.postfix.org/SASL_README.html#client_sasl
TLS: http://www.postfix.org/TLS_README.html#client_tls
 http://www.postfix.org/TLS_README.html#client_tls_policy

For the latter, you simply have to present a proper client 
certificate to their server, but you will also want a secure TLS 
connection.

> Does anyone know how postfix/amavisd/spamassassin handles this and 
> if it is at all possible? Do TLS emails bypass the spam checking or 
> do I setup rules to lower the score if they are from this source?

The amavisd-new configuration is a matter for their mailing list. I 
expect you will need a policy map to tell it to treat these mails 
specially.
-- 
  http://rob0.nodns4.us/ -- system administration and consulting
  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:

RrDNS-v-PTR

[Sam Jones]

Good Afternoon,

My senior tech and I have been having a squabble over PTR, Hostnames and
reverse mapping.

If you have a client connect from 1.2.3.4 and perform a host name lookup
on that, so you get back host.example.com, would it impact on mail if a
forward query for host.example.com returned multiple A records, say
1.2.3.4 & 5.6.7.8 alternating between the top of the result sets in a
round robin?

I ask because we've seen an slightly odd pattern to some deferrals with
a host where this happens and wonder if they may be using:

 reject_unknown_client_hostname feature, which requires not only
that the address->name and name->address mappings exist, but
also that the two mappings reproduce the client IP address. 
The unknown_client_reject_code parameter specifies the response
code for rejected requests (default: 450). The reply is always
450 in case the address->name lookup failed due to a temporary
problem. 

Sam

Re: Postfix cannot send mails when Mailscanner is added

[Stan Hoeppner]

On 4/3/2012 8:51 AM, Brian Evans - Postfix List wrote:
> On 4/3/2012 9:32 AM, Kizito Thomas wrote:

>> I am trying out Mailscanner for the first time in my life
[...]
> I highly recommend to use amavisd-new instead of Mailscanner.
[...]
> The latter uses an unsupported direct queue manipulation which is not
> guaranteed to work correctly in Postfix.

Apparently Kizito is incapable of reading the current Postfix
documentation but very capable of reading outdated articles purporting
the (non existent) benefits of Mailscanner.

From:  http://www.postfix.org/addon.html

mailscanner system, works with Postfix and other MTAs. WARNING: This
software uses unsupported methods to manipulate Postfix queue files
directly. This will result in corruption or loss of mail. The
mailscanner authors have so far refused to discuss a proper access API
or protocol.

This Mailscaner warning has been on the Postfix site for years.  AFAIK
these are Wietse's words.  Kizito, Wietse is the author of Postfix.

Still want to use Mailscanner?  If so you are on your own.  We will not
assist you with problems related to it.

-- 
Stan

Re: performance problems

[Wietse Venema]

Stan Hoeppner:
> Setting smtpd_client_connection_count_limit also sets
> postscreen_client_connection_count_limit if you're using postfix 2.8 and
> postscreen.  Thus the limit is enforced before connections are handed to
> smtpd processes, so you don't needlessly eat up additional smtpds.

Note that postscreen either blocks a client or hands it off to a
Postfix SMTP server process. The connection count limit in postscreen
applies only to the SMTP clients that are (not yet) handed off to
an SMTP server process. Once the hand-off is done, postscreen does
not know when an SMTP session ends, so the session no longer counts
towards the postscreen connection count limit. The code was tricky
enough that I did not want to introduce a postscreen-to-anvil
dependency.

The postscreen connection count limit is still effective for "hit
and run" spambots that make a burst of connections at approximately
the same time. Such clients will exceed the connection limit while
waiting for the pregreet timer to expire, or for DNS[BW]L lookups
to complete.

Wietse

Re: RrDNS-v-PTR

[Stan Hoeppner]

On 4/3/2012 9:56 AM, Sam Jones wrote:
> Good Afternoon,
> 
> My senior tech and I have been having a squabble over PTR, Hostnames and
> reverse mapping.
> 
> If you have a client connect from 1.2.3.4 and perform a host name lookup
> on that, so you get back host.example.com, would it impact on mail if a
> forward query for host.example.com returned multiple A records, say
> 1.2.3.4 & 5.6.7.8 alternating between the top of the result sets in a
> round robin?

It's possible, but the devil is in the details, which you did not
provide to us.

> I ask because we've seen an slightly odd pattern to some deferrals with
> a host where this happens and wonder if they may be using:
> 
>  reject_unknown_client_hostname feature, which requires not only
> that the address->name and name->address mappings exist, but
> also that the two mappings reproduce the client IP address. 
> The unknown_client_reject_code parameter specifies the response
> code for rejected requests (default: 450). The reply is always
> 450 in case the address->name lookup failed due to a temporary
> problem. 

This was included in your list welcome message.
http://www.postfix.org/DEBUG_README.html#mail

Please read it and post the relevant information it instructs you to.
In this case, at minimum, we need to see the SMTP responses from the
remote MTA.

-- 
Stan

Re: RrDNS-v-PTR

[/dev/rob0]

On Tue, Apr 03, 2012 at 03:56:13PM +0100, Sam Jones wrote:
> My senior tech and I have been having a squabble over PTR,
> Hostnames and reverse mapping.
> 
> If you have a client connect from 1.2.3.4 and perform a host name
> lookup on that, so you get back host.example.com, would it impact
> on mail if a forward query for host.example.com returned multiple
> A records, say 1.2.3.4 & 5.6.7.8 alternating between the top of
> the result sets in a round robin?

Multiple A records for a particular PTR value should not be a 
problem. The order in which those records are returned cannot be 
relied upon. If 192.0.2.22 connects to smtpd(8), and:

22.2.0.192.in-addr.arpa.PTR host.example.com.
host.example.com.   A   192.0.2.2
host.example.com.   A   192.0.2.22
host.example.com.   A   192.0.2.222

Postfix would log the connection as host.example.com[192.0.2.22]. 
"unknown[192.0.2.22]" is logged if:

1. 22.2.0.192.in-addr.arpa./PTR returns no value (including NXDOMAIN, 
   SERVFAIL, and NOERROR)
2. Lookup of the 22.2.0.192.in-addr.arpa./PTR value does not return
   an A record with 192.0.2.22 as value.

> I ask because we've seen an slightly odd pattern to some deferrals 
> with a host where this happens and wonder if they may be using:
> 
>   reject_unknown_client_hostname feature, which requires not only
>   that the address->name and name->address mappings exist, but
>   also that the two mappings reproduce the client IP address.

See above.
-- 
  http://rob0.nodns4.us/ -- system administration and consulting
  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:

Re: RrDNS-v-PTR

[Sam Jones]

On Tue, 2012-04-03 at 10:31 -0500, Stan Hoeppner wrote:
> On 4/3/2012 9:56 AM, Sam Jones wrote:
> > Good Afternoon,
> > 
> > My senior tech and I have been having a squabble over PTR, Hostnames and
> > reverse mapping.
> > 
> > If you have a client connect from 1.2.3.4 and perform a host name lookup
> > on that, so you get back host.example.com, would it impact on mail if a
> > forward query for host.example.com returned multiple A records, say
> > 1.2.3.4 & 5.6.7.8 alternating between the top of the result sets in a
> > round robin?
> 
> It's possible, but the devil is in the details, which you did not
> provide to us.
It really was just a general question as to how an MTA, specifically
Postfix, would respond if multiple alternating A records were returned
in respect of a forward DNS request for a PTR/Hostname connection
return.

If you don't know, that's fine - just say so. You don't need to let
yourself down with the old flame:

> 
> This was included in your list welcome message.
> http://www.postfix.org/DEBUG_README.html#mail

> Please read it and post the relevant information it instructs you to.
> In this case, at minimum, we need to see the SMTP responses from the
> remote MTA.
> 
Because I actually had gone through that, which is why I was able to
find the configuration value that could impact in such a scneario.

I do apologise for the distress, offence and disturbance my rude stupid
question has obviously caused you. I won't repeat it and I hope you can
forgive me.

Re: RrDNS-v-PTR

[Sam Jones]

On Tue, 2012-04-03 at 10:36 -0500, /dev/rob0 wrote:
> > 
> > If you have a client connect from 1.2.3.4 and perform a host name
> > lookup on that, so you get back host.example.com, would it impact
> > on mail if a forward query for host.example.com returned multiple
> > A records, say 1.2.3.4 & 5.6.7.8 alternating between the top of
> > the result sets in a round robin?
> 
> Multiple A records for a particular PTR value should not be a 
> problem. The order in which those records are returned cannot be 
> relied upon. If 192.0.2.22 connects to smtpd(8), and:
> 
> 22.2.0.192.in-addr.arpa.  PTR host.example.com.
> host.example.com. A   192.0.2.2
> host.example.com. A   192.0.2.22
> host.example.com. A   192.0.2.222
> 
> Postfix would log the connection as host.example.com[192.0.2.22]. 
> "unknown[192.0.2.22]" is logged if:
> 
> 1. 22.2.0.192.in-addr.arpa./PTR returns no value (including NXDOMAIN, 
>SERVFAIL, and NOERROR)
> 2. Lookup of the 22.2.0.192.in-addr.arpa./PTR value does not return
>an A record with 192.0.2.22 as value.
> 
Thank you rob0, that clears it up nicely. Basically, as I understand it,
if the connecting IP appears in a list of multiple A records for the
host, it won't break.

I may have lost a Pizza, but I've gained useful knowledge.

Kind thanks for your polite and very helpful reply. It is really
appreciated.

Re: RrDNS-v-PTR

[Wietse Venema]

Sam Jones:
> Good Afternoon,
> 
> My senior tech and I have been having a squabble over PTR, Hostnames and
> reverse mapping.
> 
> If you have a client connect from 1.2.3.4 and perform a host name lookup
> on that, so you get back host.example.com, would it impact on mail if a
> forward query for host.example.com returned multiple A records, say
> 1.2.3.4 & 5.6.7.8 alternating between the top of the result sets in a
> round robin?

With Postfix, multiple IP address per A record are fine, as long
as the CLIENT IP address is listed among them.

However, having multiple PTR records for one IP address, that is a
different matter. Postfix will not try to guess which name it should
use. It just takes the first name that comes up, and requires that
that name resolves to the client IP address.

Wietse

> I ask because we've seen an slightly odd pattern to some deferrals with
> a host where this happens and wonder if they may be using:
> 
>  reject_unknown_client_hostname feature, which requires not only
> that the address->name and name->address mappings exist, but
> also that the two mappings reproduce the client IP address. 
> The unknown_client_reject_code parameter specifies the response
> code for rejected requests (default: 450). The reply is always
> 450 in case the address->name lookup failed due to a temporary
> problem. 
> 
> Sam
> 
> 

Re: RrDNS-v-PTR

[Sam Jones]

On Tue, 2012-04-03 at 11:53 -0400, Wietse Venema wrote:
> With Postfix, multiple IP address per A record are fine, as long
> as the CLIENT IP address is listed among them.
> 
> However, having multiple PTR records for one IP address, that is a
> different matter. Postfix will not try to guess which name it should
> use. It just takes the first name that comes up, and requires that
> that name resolves to the client IP address. 
Thank you. That is valuable knowledge. Much appreciated.

Re: performance problems

[Stan Hoeppner]

On 4/3/2012 10:27 AM, Wietse Venema wrote:
> Stan Hoeppner:
>> Setting smtpd_client_connection_count_limit also sets
>> postscreen_client_connection_count_limit if you're using postfix 2.8 and
>> postscreen.  Thus the limit is enforced before connections are handed to
>> smtpd processes, so you don't needlessly eat up additional smtpds.
> 
> Note that postscreen either blocks a client or hands it off to a
> Postfix SMTP server process. The connection count limit in postscreen
> applies only to the SMTP clients that are (not yet) handed off to
> an SMTP server process. Once the hand-off is done, postscreen does
> not know when an SMTP session ends, so the session no longer counts
> towards the postscreen connection count limit. The code was tricky
> enough that I did not want to introduce a postscreen-to-anvil
> dependency.

Ahh, thanks for the clarification Wietse.  The
smtpd_client_connection_count_limit is still enforced against post hand
off client connections though, correct?

> The postscreen connection count limit is still effective for "hit
> and run" spambots that make a burst of connections at approximately
> the same time. Such clients will exceed the connection limit while
> waiting for the pregreet timer to expire, or for DNS[BW]L lookups
> to complete.

So the postscreen connection limit is good for slowing bots, no surprise
since bots are the postscreen target, but the smtpd connection limit is
still appropriate/needed for slowing legit bulk mailer clients, assuming
one chooses to use it vs the other anvil based restrictions.

-- 
Stan

Broken link on "Howto" page

[Jerry]

I don't know if this is really the best place to report this or not;
however, I am sure someone will say something one way or the other.

Not really an earth shattering problem; however on the
 page, under "Lookup Tables", the
one entitled: "Mysql howto by Daniel V. Pedersen. Uses the Postfix
virtual(8) delivery agent" is apparently broken.

This is the link reported: . And this is
the output:

Not Found

The requested URL /HOWTO/ was not found on this server.
Apache/2.2.20 (Ubuntu) Server at kummefryser.dk Port 80

-- 
Jerry ✌
postfix-u...@seibercom.net
_
TO REPORT A PROBLEM see http://www.postfix.org/DEBUG_README.html#mail
TO (UN)SUBSCRIBE see http://www.postfix.org/lists.html

Address re-writes

[Daniel L. Miller]

I'm sure I've done something dumb as usual - I just don't see it.

My users are all virtual and stored in LDAP.  I also have LDAP aliases.  
I also have recipient, sender, canonical, and transport entries.


I have defined a particular alias in LDAP - this alias is mapped to two 
users.  If I send a message to that alias, using Hotmail as an external 
test, it processes correctly.


From main.cf:
smtpd_sender_restrictions =
reject_unlisted_sender,
check_sender_access hash:/etc/postfix/maps/fax-access

and fax-access:
mess...@inbound.efax.comREDIRECTtheal...@amfes.com

It appears that the redirection occurs - but then is handed to the lda 
for delivery, without resolving the alias.  This used to work when I was 
using a simple mailbox - but is now broken when using the alias.


--
Daniel

verify database error

[Daniel L. Miller]

I keep seeing the following in the log:

postfix/verify[27427]: close database /var/lib/postfix/verify.db: No 
such file or directory


Yet...
ls -al /var/lib/postfix/verify.db:
-rw-rw-rw-  1 postfix postfix 1564672 2012-04-03 09:47 verify.db

Why?  This is on Linux 2.6.35 and XFS if it makes a difference.
--
Daniel

Re: RrDNS-v-PTR

[Stan Hoeppner]

On 4/3/2012 10:41 AM, Sam Jones wrote:
> On Tue, 2012-04-03 at 10:31 -0500, Stan Hoeppner wrote:

>> It's possible, but the devil is in the details, which you did not
>> provide to us.

> It really was just a general question as to how an MTA, specifically
> Postfix, would respond if multiple alternating A records were returned
> in respect of a forward DNS request for a PTR/Hostname connection
> return.
> 
> If you don't know, that's fine - just say so. You don't need to let
> yourself down with the old flame:

>> This was included in your list welcome message.
>> http://www.postfix.org/DEBUG_README.html#mail

>> Please read it and post the relevant information it instructs you to.
>> In this case, at minimum, we need to see the SMTP responses from the
>> remote MTA.

> Because I actually had gone through that, which is why I was able to
> find the configuration value that could impact in such a scneario.
> 
> I do apologise for the distress, offence and disturbance my rude stupid
> question has obviously caused you. I won't repeat it and I hope you can
> forgive me.

Re-reading what I wrote, and reading your reply, leaves me at a bit of a
loss as to what prompted this immature drivel.  My reply was totally
professional, if dry and somewhat canned.  But how such would prompt a
reply like this escapes me.  Maybe you're just having a bad day?

-- 
Stan

Re: performance problems

[Wietse Venema]

Stan Hoeppner:
> So the postscreen connection limit is good for slowing bots, no surprise
> since bots are the postscreen target, but the smtpd connection limit is
> still appropriate/needed for slowing legit bulk mailer clients, assuming
> one chooses to use it vs the other anvil based restrictions.

Correct. postscreen by design has no effect on known, non-bot, clients.

Wietse

Re: RrDNS-v-PTR

[Sam Jones]

> > I do apologise for the distress, offence and disturbance my rude stupid
> > question has obviously caused you. I won't repeat it and I hope you can
> > forgive me.
> 
> Re-reading what I wrote, and reading your reply, leaves me at a bit of a
> loss as to what prompted this immature drivel.  My reply was totally
> professional, if dry and somewhat canned.  But how such would prompt a
> reply like this escapes me.  Maybe you're just having a bad day?
> 
I really don't want to start a war. I'm old, tired and underpaid, but
you were rude, and quite unnecessarily so. You don't seem to be able to
help it, because when I was perfectly polite to you - if a touch
sarcastic in return to your 'dry and canned' response, you then went on
to describe it as 'immature drivel' - which, I'm sure you would agree,
is somewhat unprofessional and quite hypocritical.

I'm sorry you did not know the answer, but the question has now been
addressed very professionally by polite, skilled people - to whom I am
most grateful and obliged.

I'm sorry to have troubled you.

Re: Address re-writes

[Wietse Venema]

Daniel L. Miller:
> I'm sure I've done something dumb as usual - I just don't see it.
> 
> My users are all virtual and stored in LDAP.  I also have LDAP aliases.  
> I also have recipient, sender, canonical, and transport entries.
> 
> I have defined a particular alias in LDAP - this alias is mapped to two 
> users.  If I send a message to that alias, using Hotmail as an external 
> test, it processes correctly.
> 
>  From main.cf:
> smtpd_sender_restrictions =
>  reject_unlisted_sender,
>  check_sender_access hash:/etc/postfix/maps/fax-access
> 
> and fax-access:
> mess...@inbound.efax.comREDIRECTtheal...@amfes.com

As documented, REDIRECT affects all recipients. It is meant to yank
mail out of its normal path, and was originally implemented for
emergencies (that is also why the feature is not subject to canonical,
virtual alias, or BCC address mappings, and none of this is properly
documented).

In other words, don't use REDIRECT for routine mail processing.

Wietse

> It appears that the redirection occurs - but then is handed to the lda 
> for delivery, without resolving the alias.  This used to work when I was 
> using a simple mailbox - but is now broken when using the alias.
> 
> -- 
> Daniel
> 

Re: verify database error

[Wietse Venema]

Daniel L. Miller:
> I keep seeing the following in the log:
> 
> postfix/verify[27427]: close database /var/lib/postfix/verify.db: No 
> such file or directory


/*
 * With some Berkeley DB implementations, close fails with a bogus ENOENT
 * error, while it reports no errors with put+sync, no errors with
 * del+sync, and no errors with the sync operation just before this
 * comment. This happens in programs that never fork and that never share
 * the database with other processes. The bogus close error has been
 * reported for programs that use the first/next iterator. Instead of
 * making Postfix look bad because it reports errors that other programs
 * ignore, I'm going to report the bogus error as a non-error.
 */
if (DICT_DB_CLOSE(dict_db->db) < 0)
msg_info("close database %s: %m (possible Berkeley DB bug)",
 dict_db->dict.name);

Re: Address re-writes

[Daniel L. Miller]

On 4/3/2012 10:27 AM, Wietse Venema wrote:

Daniel L. Miller:

and fax-access:
mess...@inbound.efax.comREDIRECTtheal...@amfes.com

As documented, REDIRECT affects all recipients. It is meant to yank
mail out of its normal path, and was originally implemented for
emergencies (that is also why the feature is not subject to canonical,
virtual alias, or BCC address mappings, and none of this is properly
documented).

In other words, don't use REDIRECT for routine mail processing.




Ok - I'm using the wrong tool for the job.  So - please let me rephrase 
my question.


What would be the proper way to redirect inbound mail originally 
destined for a valid user, to an alias which can be expanded/redirected 
through normal handling, based on the sender?

--
Daniel

Re: verify database error

[Daniel L. Miller]

On 4/3/2012 10:32 AM, Wietse Venema wrote:

Daniel L. Miller:

I keep seeing the following in the log:

postfix/verify[27427]: close database /var/lib/postfix/verify.db: No
such file or directory


 /*
  * With some Berkeley DB implementations, close fails with a bogus ENOENT
  * error, while it reports no errors with put+sync, no errors with
  * del+sync, and no errors with the sync operation just before this
  * comment. This happens in programs that never fork and that never share
  * the database with other processes. The bogus close error has been
  * reported for programs that use the first/next iterator. Instead of
  * making Postfix look bad because it reports errors that other programs
  * ignore, I'm going to report the bogus error as a non-error.
  */
 if (DICT_DB_CLOSE(dict_db->db)<  0)
 msg_info("close database %s: %m (possible Berkeley DB bug)",
  dict_db->dict.name);



I'm currently using Postfix 2.7.1, with libdb4.8.  Will an upgrade to 
either or both of these correct the issue?


--
Daniel

Re: Address re-writes

[Wietse Venema]

Daniel L. Miller:
> On 4/3/2012 10:27 AM, Wietse Venema wrote:
> > Daniel L. Miller:
> >> and fax-access:
> >> mess...@inbound.efax.comREDIRECTtheal...@amfes.com
> > As documented, REDIRECT affects all recipients. It is meant to yank
> > mail out of its normal path, and was originally implemented for
> > emergencies (that is also why the feature is not subject to canonical,
> > virtual alias, or BCC address mappings, and none of this is properly
> > documented).
> >
> > In other words, don't use REDIRECT for routine mail processing.
> 
> Ok - I'm using the wrong tool for the job.  So - please let me rephrase 
> my question.
> 
> What would be the proper way to redirect inbound mail originally 
> destined for a valid user, to an alias which can be expanded/redirected 
> through normal handling, based on the sender?

So you want to replace the recipient only some of the time,
but not all of the time. That is not built into Postfix.

Yesterday someone asked for size-dependent delivery paths. With
enough of such features, the mail system becomes really hard to
understand, like firewall rules.

Wietse

Re: RrDNS-v-PTR

[Stan Hoeppner]

On 4/3/2012 12:18 PM, Sam Jones wrote:
> 
>>> I do apologise for the distress, offence and disturbance my rude stupid
>>> question has obviously caused you. I won't repeat it and I hope you can
>>> forgive me.
>>
>> Re-reading what I wrote, and reading your reply, leaves me at a bit of a
>> loss as to what prompted this immature drivel.  My reply was totally
>> professional, if dry and somewhat canned.  But how such would prompt a
>> reply like this escapes me.  Maybe you're just having a bad day?
>>
> I really don't want to start a war. 

Disingenuous as you intended to, and continue it.

> I'm old, tired and underpaid, but

Pull sympathy strings.

> you were rude, and quite unnecessarily so. You don't seem to be able to
> help it, because when I was perfectly polite to you - if a touch

Reverse projection, fabrication.

> sarcastic in return to your 'dry and canned' response, you then went on
> to describe it as 'immature drivel' - which, I'm sure you would agree,
> is somewhat unprofessional and quite hypocritical.

So sarcasm isn't rude, but my calling it out is rude.  Calling me
unprofessional after I pointed out my post was professional.  Calling me
a hypocrite.  More reverse projection.

> I'm sorry you did not know the answer, but the question has now been
> addressed very professionally by polite, skilled people - to whom I am
> most grateful and obliged.

False assumption plus backhanded insults.

> I'm sorry to have troubled you.

Disingenuous.

Normally I would have simply ignored your baseless rude remarks.  But
you made a personal attack out of your reply.  Drawing you out a little
more has clearly demonstrated to everyone who and what you are, so my
job is done, so to speak.  Feel free to have the last word, including
any/all additional baseless insults you wish.

P.S. be sure in the future to tell Wietse he doesn't know the answer
every time he prompts a poster to follow the list instructions. :)

-- 
Stan

STOP THE PISSING CONTEXT (RrDNS-v-PTR)

[Wietse Venema]

Guys, have your pissing context somewhere else.

Re: TLS Emails

[Viktor Dukhovni]

On Tue, Apr 03, 2012 at 09:39:22AM -0500, /dev/rob0 wrote:

> > One of these domains in particular is a remote site with their
> > own Exchange 2007 server and they have asked me to allow TLS
> > emails through, HSBC Bank is asking for this.
> 
> I don't think the request is reasonable, but it is easy to do. A 
> restriction class for this recipient domain, checked after 
> reject_unauth_destination, which calls permit_tls_all_clientcerts.

This is definitely NOT what the client is asking for. They want
their business partners to be able to encrypt email in transit
via TLS. This just means that the OP needs to:

- Install a SSL cert on his inbound systems, issued by a
  a mutually agreeable pubic CA. This is done by configuring
  the cert and key and setting smtpd_tls_security_level = may.

- Enable mandatory ("encrypt") or secure-channel ("secure")
  TLS encryption for scanned mail that is relayed to the
  requested client. This is done via smtpd_tls_policy_maps.

Both of these are easy and are documented the TLS for SMTP servers
and TLS for SMTP clients sections of TLS_README. 

If the client's business partners want secure-channel connections, not
just mandatory TLS with no authentication, they'll need to know what
CAs to expect in the server cert and which DNS names or name suffixes
will be associated with this service. They'll need to be notified in
advance of any cert updates (beyond simple renewal) that introduce
new DNS suffixes or new public CAs.

Ideally the uplink to the client is secure-channel, so that there is
no mismatch between sender expectation of security and reality.

-- 
Viktor.

Re: verify database error

[lst_hoe02]

Zitat von "Daniel L. Miller" :


On 4/3/2012 10:32 AM, Wietse Venema wrote:

Daniel L. Miller:

I keep seeing the following in the log:

postfix/verify[27427]: close database /var/lib/postfix/verify.db: No
such file or directory


/*
 * With some Berkeley DB implementations, close fails with a  
bogus ENOENT

 * error, while it reports no errors with put+sync, no errors with
 * del+sync, and no errors with the sync operation just before this
 * comment. This happens in programs that never fork and that  
never share

 * the database with other processes. The bogus close error has been
 * reported for programs that use the first/next iterator. Instead of
 * making Postfix look bad because it reports errors that other programs
 * ignore, I'm going to report the bogus error as a non-error.
 */
if (DICT_DB_CLOSE(dict_db->db)<  0)
msg_info("close database %s: %m (possible Berkeley DB bug)",
 dict_db->dict.name);



I'm currently using Postfix 2.7.1, with libdb4.8.  Will an upgrade  
to either or both of these correct the issue?


With Postfix update you might "cleanup" the error message, with  
Berkeley DB update you can clean up the root-cause. But be aware that  
you should not mix-up different DB versions on the same host.


Regards

Andreas



smime.p7s
Description: S/MIME Cryptographic Signature

Re: defer mail for unknown recipients for one domain only

[Wietse Venema]

Wietse Venema:
> The implicit "unknown recipient" test at the end is not part of
> smtpd_recipient_restrictions, and this implicit test currently does
> not play along with any defer_if features requested from within
> smtpd_recipient_restrictions.

I finally had some time to check this. It seems that "defer_if_reject"
works as usual. The implicit "reject_unlisted_recipient" at the end
of smtpd_recipient_restrictions will defer mail thanks to massive
code reuse inside Postfix:

% postconf smtpd_recipient_restrictions
smtpd_recipient_restrictions = reject_unauth_destination,defer_if_reject
% postfix reload
postfix/postfix-script: refreshing the Postfix mail system
% telnet 127.0.0.1 smtp
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 bristle.watson.ibm.com ESMTP Postfix
mail from:wietse
250 2.1.0 Ok
rcpt to:AKJDK@localhost
450 4.7.0 : Recipient address rejected: defer_if_reject 
requested

I get the same result by adding an explicit "reject_unlisted_recipient"
after "defer_if_reject" in the example above.

So it looks like it is possible to defer (most) non-existent
recipients by putting "defer_if_reject" at the end of
smtpd_recipient_restrictions.

Wietse

Re: defer mail for unknown recipients for one domain only

[Wietse Venema]

Wietse Venema:
> Wietse Venema:
> > The implicit "unknown recipient" test at the end is not part of
> > smtpd_recipient_restrictions, and this implicit test currently does
> > not play along with any defer_if features requested from within
> > smtpd_recipient_restrictions.
> 
> I finally had some time to check this. It seems that "defer_if_reject"
> works as usual. The implicit "reject_unlisted_recipient" at the end
> of smtpd_recipient_restrictions will defer mail thanks to massive
> code reuse inside Postfix:
> 
> % postconf smtpd_recipient_restrictions
> smtpd_recipient_restrictions = reject_unauth_destination,defer_if_reject
> % postfix reload
> postfix/postfix-script: refreshing the Postfix mail system
> % telnet 127.0.0.1 smtp
> Trying 127.0.0.1...
> Connected to localhost.
> Escape character is '^]'.
> 220 bristle.watson.ibm.com ESMTP Postfix
> mail from:wietse
> 250 2.1.0 Ok
> rcpt to:AKJDK@localhost
> 450 4.7.0 : Recipient address rejected: defer_if_reject 
> requested
> 
> I get the same result by adding an explicit "reject_unlisted_recipient"
> after "defer_if_reject" in the example above.

To soft-reject unknown recipients in selected domains, in mail from
clients outside the local network, request defer_if_reject at the end
of smtpd_recipient_restrictions:

/etc/postfix/main.cf:
smtpd_recipient_restrictions =
permit_mynetworks
...
reject_unauth_destination
...
check_recipient_access hash:/etc/postfix/final_rcpt_access

/etc/postfix/final_rcpt_access:
example.com defer_if_reject

This is approximately the solution that Rob0 proposed.

You could drop "permit_mynetworks" when this service is not
used for original submissions.

Wietse

Re: Address re-writes

[Daniel L. Miller]

On 4/3/2012 11:03 AM, Wietse Venema wrote:

Daniel L. Miller:

On 4/3/2012 10:27 AM, Wietse Venema wrote:

Daniel L. Miller:

and fax-access:
mess...@inbound.efax.comREDIRECTtheal...@amfes.com

As documented, REDIRECT affects all recipients. It is meant to yank
mail out of its normal path, and was originally implemented for
emergencies (that is also why the feature is not subject to canonical,
virtual alias, or BCC address mappings, and none of this is properly
documented).

In other words, don't use REDIRECT for routine mail processing.

Ok - I'm using the wrong tool for the job.  So - please let me rephrase
my question.

What would be the proper way to redirect inbound mail originally
destined for a valid user, to an alias which can be expanded/redirected
through normal handling, based on the sender?

So you want to replace the recipient only some of the time,
but not all of the time. That is not built into Postfix.

Yesterday someone asked for size-dependent delivery paths. With
enough of such features, the mail system becomes really hard to
understand, like firewall rules.



I think a broader statement for what I'm looking for is to be able to 
re-write the recipient based on the sender, and vice versa.  If Postfix 
does not support this, do you know of a tool that does that I can use as 
a proxy/filter?

--
Daniel

Re: Address re-writes

[Noel Jones]

On 4/3/2012 10:28 PM, Daniel L. Miller wrote:
> 
> I think a broader statement for what I'm looking for is to be able
> to re-write the recipient based on the sender, and vice versa.  If
> Postfix does not support this, do you know of a tool that does that
> I can use as a proxy/filter?

A milter should be able to do what you want.  Look around at some of
the ones available.


  -- Noel Jones

Re: Postfix cannot send mails when Mailscanner is added

[Kizito Thomas]

Thank you good members,
I have to be sincere, I did not know that Mailscanner was not supported
by Postfix. I was trying it because there is a mail server (supporting
one of my emails) running on postfix which uses Mailscanner and I
thought I could emulate. Otherwise am sorry for spamming your boxes with
wrong forum staff, but it takes a mistake to learn. I have learnt and
hope to change. Thank you for this.
I am going to try and see whether I can install amavisd-new as advised
by Brian Evans in the earlier response... Thank you so much. 
-- 
..
Seat of Wisdom ..Pray for us
Cause of our Joy...Pray for us
...
Mayengo Tom Kizito
+256-752-602550
+256-782-062708 

-Original Message-
From: Stan Hoeppner 
Reply-to: s...@hardwarefreak.com
To: postfix-users@postfix.org
Subject: Re: Postfix cannot send mails when Mailscanner is added
Date: Tue, 03 Apr 2012 10:14:15 -0500


On 4/3/2012 8:51 AM, Brian Evans - Postfix List wrote:
> On 4/3/2012 9:32 AM, Kizito Thomas wrote:

>> I am trying out Mailscanner for the first time in my life
[...]
> I highly recommend to use amavisd-new instead of Mailscanner.
[...]
> The latter uses an unsupported direct queue manipulation which is not
> guaranteed to work correctly in Postfix.

Apparently Kizito is incapable of reading the current Postfix
documentation but very capable of reading outdated articles purporting
the (non existent) benefits of Mailscanner.

From:  http://www.postfix.org/addon.html

mailscanner system, works with Postfix and other MTAs. WARNING: This
software uses unsupported methods to manipulate Postfix queue files
directly. This will result in corruption or loss of mail. The
mailscanner authors have so far refused to discuss a proper access API
or protocol.

This Mailscaner warning has been on the Postfix site for years.  AFAIK
these are Wietse's words.  Kizito, Wietse is the author of Postfix.

Still want to use Mailscanner?  If so you are on your own.  We will not
assist you with problems related to it.