Re: smtpd_restrictions sanity check

[Ralf Hildebrandt]

* Alex :

> reject_maps_rbl,

That's deprecated, for years.

-- 
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

Re: smtpd_recipient_restrictions evaluation question

[Simon Morvan]

Stan Hoeppner a écrit :

Simon Morvan put forth on 10/31/2009 12:30 PM:

  

And why shouldn't be able to use my own mail server behind my private
residential ADSL line ?



You should be able to.  Here's how to implement the outbound mail
portion to prevent mass rejections:

http://www.hardwarefreak.com/postfix-adsl-relay-config.txt

--
Stan
  
That's prevent rejection but also prevent my ability to ensure my 
freedom to use the network :

http://en.wikipedia.org/wiki/Network_neutrality

That's will be my last message on-list for this topic but feel free to 
keep on discuss this off-list :)


--
Simon.

Re: Postfix-SASL-GSSAPI question

[Ali Majdzadeh]

Viktor,
Hello
Thanks a lot for your help. I managed to solve the problem. By the way, have
you got any experiences about using kerberos as a pam module?

Kind Regards
Ali Majdzadeh Kohbanani

2009/10/30 Ali Majdzadeh 

> Viktor,
> Hi
> Thanks for your guidance. Would please keep an eye on this thread? I am
> going to test the configuration using a properly configured GSSAPI client.
> Possibly, there will be much more questions to ask ;)
> Thank you so much.
>
>
> Kind Regards
> Ali Majdzadeh Kohbanani
>
> 2009/10/29 Victor Duchovni 
>
>> On Thu, Oct 29, 2009 at 07:11:54PM +0330, Ali Majdzadeh wrote:
>>
>>
>> > Thanks for your mail. Among your experiences with Postfix, GSSAPI and
>> > probably SASL, have you ever tested your configuration using telnet? If
>> it
>> > is so, would you please describe the procedure? According to your
>> previous
>> > mail, I figured out that since I use telnet to test the configuration, I
>> > should know about the exact handshake process.
>>
>> The GSSAPI handshake is too complex for hand-tests with telnet.  Use a
>> real GSSAPI client, e.g. a suitably configured Postfix client.
>>
>> --
>> Viktor.
>>
>> Disclaimer: off-list followups get on-list replies or get ignored.
>> Please do not ignore the "Reply-To" header.
>>
>> To unsubscribe from the postfix-users list, visit
>> http://www.postfix.org/lists.html or click the link below:
>> 
>>
>> If my response solves your problem, the best way to thank me is to not
>> send an "it worked, thanks" follow-up. If you must respond, please put
>> "It worked, thanks" in the "Subject" so I can delete these quickly.
>>
>
>

Problem using Postfix, saslauthd and pam_krb5

[Ali Majdzadeh]

Hello all
I have configured saslauthd to use pam for password verification and I want
to use pam_krb5 as the authentication back-end. I have set the following
options in /etc/postfix/sasl/smtpd.conf:

log_level: 3
pwcheck_method: saslauthd
mech_list: plain login

Also, I have entered the following lines in /etc/pam.d/smtp

authsufficient  /lib/security/pam_krb5.so minimum_uid=1000
session required/lib/security/pam_krb5.so minimum_uid=1000
account required/lib/security/pam_krb5.so minimum_uid=1000
passwordsufficient  /lib/security/pam_krb5.so minimum_uid=1000

When I use testsaslauthd as "testsaslauthd -u user -p pass -s smtp -f
/var/run/saslauthd/mux", it can successfully authenticate the user which has
a corresponding principal in my kerberos configuration. But, when I want to
use telnet to actually test the smtp server, the authentication fails. By
the way, what should be provided to the server when the desired
authentication mechanism is plain? (Is that something like:  perl
-MMIME::Base64 -e 'print encode_base64("user\0pass")')? And the last
questions, are all those configuration file names (and definitely) their
content correct? I mean, /etc/postfix/smtpd.conf and /etc/pam.d/smtp?

Kind Regards
Ali Majdzadeh Kohbanani

smtpd_recipient_restrictions evaluation question

[Stan Hoeppner]

Simon Morvan put forth on 11/1/2009 4:20 AM:

> That's prevent rejection but also prevent my ability to ensure my
> freedom to use the network :
> http://en.wikipedia.org/wiki/Network_neutrality
> 
> That's will be my last message on-list for this topic but feel free to
> keep on discuss this off-list :)

Net Neutrality has nothing to do with SMTP receivers.  It has everything
to do with network carriers and QOS.  You have no inherent right to send
email to _my_ MX, nor anyone else's.  Your rights end where mine begin.
 If I chose to drop your SMTP connections due to the rDNS name of your
sending MTA, its status as being listed in the Spamhaus PBL, or any
other reason, that's my right, and dropping you does not in any way
infringe upon _your_ rights, because in this case, again, you have no
rights.

If, after reading this, you feel that receivers who reject mail sent
directly from your residential IP are infringing upon your rights, then
we can safely file your comments into the kook folder.

--
Stan

Re: smtpd_recipient_restrictions evaluation question

[Daniel V. Reinhardt]

- Original Message 

> From: Stan Hoeppner 
> To: postfix-users@postfix.org
> Sent: Sun, November 1, 2009 1:00:30 PM
> Subject: smtpd_recipient_restrictions evaluation question
> 
> Simon Morvan put forth on 11/1/2009 4:20 AM:
> 
> > That's prevent rejection but also prevent my ability to ensure my
> > freedom to use the network :
> > http://en.wikipedia.org/wiki/Network_neutrality
> > 
> > That's will be my last message on-list for this topic but feel free to
> > keep on discuss this off-list :)
> 
> Net Neutrality has nothing to do with SMTP receivers.  It has everything
> to do with network carriers and QOS.  You have no inherent right to send
> email to _my_ MX, nor anyone else's.  Your rights end where mine begin.
> If I chose to drop your SMTP connections due to the rDNS name of your
> sending MTA, its status as being listed in the Spamhaus PBL, or any
> other reason, that's my right, and dropping you does not in any way
> infringe upon _your_ rights, because in this case, again, you have no
> rights.
> 
> If, after reading this, you feel that receivers who reject mail sent
> directly from your residential IP are infringing upon your rights, then
> we can safely file your comments into the kook folder.
> 
> --
> Stan

Very well said Stan.  Residential IP's are common to be malware infected with 
malware that sends itself out via its own SMTP program, and as such should be 
stopped.  

Thanks,
Dan



  

Re: smtpd_recipient_restrictions evaluation question

[Jerry]

On Sun, 01 Nov 2009 07:00:30 -0600
Stan Hoeppner  replied:

[snip]

>Net Neutrality has nothing to do with SMTP receivers.  It has
>everything to do with network carriers and QOS.  You have no inherent
>right to send email to _my_ MX, nor anyone else's.  Your rights end
>where mine begin.
> If I chose to drop your SMTP connections due to the rDNS name of your
>sending MTA, its status as being listed in the Spamhaus PBL, or any
>other reason, that's my right, and dropping you does not in any way
>infringe upon _your_ rights, because in this case, again, you have no
>rights.
>
>If, after reading this, you feel that receivers who reject mail sent
>directly from your residential IP are infringing upon your rights, then
>we can safely file your comments into the kook folder.

Better yet, stop sending them e-mail.

--  
Jerry
postfix.u...@yahoo.com

TO REPORT A PROBLEM see http://www.postfix.org/DEBUG_README.html#mail
TO (UN)SUBSCRIBE see http://www.postfix.org/lists.html

Another megabytes the dust.

Re: Please evaluate my understanding wrt access files

[mouss]

Stan Hoeppner a écrit :
> mouss put forth on 10/31/2009 11:06 AM:
> 
> mouss, you rock.
> 
>> you can use a script if you prefer. the advantage of 'make' is that it
>> only re-generates files when needed (source change).
> 
> The only likely changes would be adding another country. 

sometimes, you find a new IP that wasn't there, or an IP is assigned to
another country... rare, but may happen.

> In this case,
> would I just add the file name to the "source" section below, and run
> the make script?
> 

yes, just add a
COUNTRIES += nowhereland
line and it should work.

>> [snip]
> Neat.  I'm using gnu make so this should all work.  Still don't
> understand how this would affect memory footprint, but at least it would
> clean up my main.cf a bit.
> 

it is faster to search a single file, rather than doing 10 searches.
Think of an IP that is not listed in any of your country maps. with 10
files, you multiply the number of lookups by 10 compared to searching in
a single file.

of course latency isn't a problem in your setup. but beauty is enough
reason! see below.

>> PS. since you use a cidr specific directory, you can get rid of the
>> ".cidr" suffix. you could then use (in main.cf):
>>
>> cidr=cidr:/etc/postfix/cidr_files
>> smtpd_foo_restrictions =
>>  ...
>>  check_client_access ${cidr}/access_foo
>>  ...
>>  check_client_access ${cidr}/access_bar
> 
> Ahh, also sweet.  I'd seen folks using variables but I hadn't really
> found a need yet to dig into it.  That and I was afraid of confusing
> myself down the road. ;)  Just implemented this.  Works fine, main.cf
> much cleaner looking, 


yep. it avoids repetition and long lines.

maps_dir = /etc/postfix/maps
cdb = cdb:${maps_dir}/cdb
pcre = pcre:${maps_dir}/pcre
mysql = mysql:${maps_dir}/mysql
...

virtual_mailbox_maps =
${sql}/virtual_mailbox

virtual_alias_maps =
${sql}/virtual_alias

smtpd_foo_restrictions =

# per recipient access rules
check_recipient_access ${mysql}/access_recipient
check_recipient_access ${pcre}/access_recipient
...
# selectively reject mail from "generic rDNS" and invalid PTR:
check_helo_access ${sql}/access_host
check_helo_access ${pcre}/access_host
check_reverse_client_hostname_access ${sql}/access_host
check_reverse_client_hostname_access ${pcre}/access_host
...


PS. on the other hand, postconf -n doesn't show the custom variables.
but this shouldn't be a problem as long as you don't abuse variables.



>_and_ I'm now practicing "good form" with
> "check_client_access" in front of each CIDR map. ;)
> 

yes. this will allow you to move/copy checks between different
restrictions. In particular, you can move checks to a restriction class
withouth having to wonder which restriction calls the class. (yes, I am
not very clear. but I hope you see what I mean ;-).


> Lots of good ancillary info coming out of this thread.  Thanks guys.
> Still wondering about the map file memory overhead details...
> 
> --
> Stan

Re: smtpd_recipient_restrictions evaluation question

[Simon Morvan]

Daniel V. Reinhardt a écrit :

- Original Message 

  

From: Stan Hoeppner 
To: postfix-users@postfix.org
Sent: Sun, November 1, 2009 1:00:30 PM
Subject: smtpd_recipient_restrictions evaluation question

Simon Morvan put forth on 11/1/2009 4:20 AM:



That's prevent rejection but also prevent my ability to ensure my
freedom to use the network :
http://en.wikipedia.org/wiki/Network_neutrality

That's will be my last message on-list for this topic but feel free to
keep on discuss this off-list :)
  

Net Neutrality has nothing to do with SMTP receivers.  It has everything
to do with network carriers and QOS.  You have no inherent right to send
email to _my_ MX, nor anyone else's.  Your rights end where mine begin.
If I chose to drop your SMTP connections due to the rDNS name of your
sending MTA, its status as being listed in the Spamhaus PBL, or any
other reason, that's my right, and dropping you does not in any way
infringe upon _your_ rights, because in this case, again, you have no
rights.

If, after reading this, you feel that receivers who reject mail sent
directly from your residential IP are infringing upon your rights, then
we can safely file your comments into the kook folder.

--
Stan



Very well said Stan.  Residential IP's are common to be malware infected with malware that sends itself out via its own SMTP program, and as such should be stopped.  


Thanks,
Dan



  
  
And how am I supposed to send mail from my own mail server if I don't 
trust my ISP mail relay nor have $$$ to have a colo space and my own IP 
space ?


And, Stan, you refuse mails from my ISP mail relay... (the second 
biggest in France...)


--
Simon

Re: smtpd_restrictions sanity check

[mouss]

Alex a écrit :
> Hi all,
> 
> Hopefully I don't have the most frequently asked question, but I'm
> spinning my wheels and perhaps followed some bad advice. I hoped
> someone could look over my recipient restrictions to see if I'm making
> some kind of mistake:
> 
> smtpd_recipient_restrictions =
> reject_invalid_hostname,
> reject_non_fqdn_hostname,
> reject_non_fqdn_sender,
> reject_non_fqdn_recipient,
> reject_unknown_sender_domain,
> reject_unknown_recipient_domain,
> reject_unauth_pipelining,
> check_client_access hash:/etc/postfix/client_checks,
> check_recipient_access pcre:/etc/postfix/relay_recips_checks,
> check_helo_access hash:/etc/postfix/helo_checks,
> check_sender_access hash:/etc/postfix/sender_checks,
> check_sender_access hash:/etc/postfix/disallow_my_domain,
> permit_mynetworks,
> check_recipient_access pcre:/etc/postfix/recipient_checks,
> reject_unauth_destination,
> reject_maps_rbl,
> permit
> 


smtpd_recipient_restrictions =
reject_non_fqdn_sender
reject_non_fqdn_recipient
permit_mynetworks
#permit_sasl_authenticated
reject_unauth_destination
#
reject_invalid_hostname
reject_non_fqdn_hostname
reject_unknown_sender_domain
#
check_client_access hash:/etc/postfix/client_checks
check_recipient_access pcre:/etc/postfix/relay_recips_checks
check_helo_access hash:/etc/postfix/helo_checks
check_sender_access hash:/etc/postfix/sender_checks
check_sender_access hash:/etc/postfix/disallow_my_domain
check_recipient_access pcre:/etc/postfix/recipient_checks
#
reject_rbl_client zen.spamhaus.org



> I originally had permit_mynetworks further up, but it seems
> client_checks was then being ignored, despite the client not being on
> my network.
> 
> I'm now trying to provide a mail server that is not part of my
> networks to my network.
> 
> I also have a handful of cron scripts that run on this remote network
> that send mail to my network, but with internal hostnames that aren't
> resolvable once they reach my network. Do I just add them to my
> postfix hosts file or is there a way to avoid checking the hostname
> (sender access?) so they aren't rejected with "Sender address
> rejected: Domain not found"?
> 
> Thanks,
> Alex

Re: smtpd_recipient_restrictions evaluation question

[Daniel V. Reinhardt]

- Original Message 
> From: Simon Morvan 
> To: postfix-users@postfix.org
> Sent: Sun, November 1, 2009 2:37:14 PM
> Subject: Re: smtpd_recipient_restrictions evaluation question
> 
> Daniel V. Reinhardt a écrit :
> > - Original Message 
> >
> >  
> >> From: Stan Hoeppner 
> >> To: postfix-users@postfix.org
> >> Sent: Sun, November 1, 2009 1:00:30 PM
> >> Subject: smtpd_recipient_restrictions evaluation question
> >>
> >> Simon Morvan put forth on 11/1/2009 4:20 AM:
> >>
> >>
> >>> That's prevent rejection but also prevent my ability to ensure my
> >>> freedom to use the network :
> >>> http://en.wikipedia.org/wiki/Network_neutrality
> >>>
> >>> That's will be my last message on-list for this topic but feel free to
> >>> keep on discuss this off-list :)
> >>>  
> >> Net Neutrality has nothing to do with SMTP receivers.  It has everything
> >> to do with network carriers and QOS.  You have no inherent right to send
> >> email to _my_ MX, nor anyone else's.  Your rights end where mine begin.
> >> If I chose to drop your SMTP connections due to the rDNS name of your
> >> sending MTA, its status as being listed in the Spamhaus PBL, or any
> >> other reason, that's my right, and dropping you does not in any way
> >> infringe upon _your_ rights, because in this case, again, you have no
> >> rights.
> >>
> >> If, after reading this, you feel that receivers who reject mail sent
> >> directly from your residential IP are infringing upon your rights, then
> >> we can safely file your comments into the kook folder.
> >>
> >> --
> >> Stan
> >>
> >
> > Very well said Stan.  Residential IP's are common to be malware infected 
> > with 
> malware that sends itself out via its own SMTP program, and as such should be 
> stopped.  
> >
> > Thanks,
> > Dan
> >
> >
> >
> >  
> >  
> And how am I supposed to send mail from my own mail server if I don't 
> trust my ISP mail relay nor have $$$ to have a colo space and my own IP 
> space ?
> 
> And, Stan, you refuse mails from my ISP mail relay... (the second 
> biggest in France...)
> 
> -- 
> Simon

Simple you get a business account, and have them edit your rDNS and other 
important records accordingly.  Residential IP's shouldn't be allowed to send 
mail except from their own ISP Mail Server.  If you don't trust your ISP, then 
its time to find another one.

Re: smtpd_recipient_restrictions evaluation question

[mouss]

Simon Morvan a écrit :
> Le 30/10/2009 16:05, /dev/rob0 a écrit :
>>[snip]
>>>  
>> Consider Zen here. It also incorporates the (not-quite-so) new PBL,
>> which has been very effective here.
>>
>>
> The last time I tried it, Zen included too many legitimate users behind
> ADSL lines. The "Policy" behind PBL is a bit too restrictive. Maybe it
> changed, I'll give it another try.

AFAIK, the policy didn't change. but chances are that people who used to
send directly have moved to a relay model. The PBL is used in many
places. and some large sites use more restrictive lists anyway. so
insisting on sending directly only causes grief, and things are mostly
likely to "get worse".

I personally use dnswl.org. so users who get blocked by the PBL are
invited to submit their IP to dnswl.org.


>>> reject_rhsbl_sender dsn.rfc-ignorant.org,

you find PBL policy too restrictive, yet you use a non-spam related
list. anyway, your server your rules...

>> [snip]

Re: smtpd_recipient_restrictions evaluation question

[/dev/rob0]

On Sunday 01 November 2009 12:24:54 mouss wrote:
> Simon Morvan a écrit :
> > Le 30/10/2009 16:05, /dev/rob0 a écrit :
> >>[snip]
> >>
> >> Consider Zen here. It also incorporates the (not-quite-so) new PBL,
> >> which has been very effective here.
> >
> > The last time I tried it, Zen included too many legitimate users behind
> > ADSL lines. The "Policy" behind PBL is a bit too restrictive. Maybe it
> > changed, I'll give it another try.
>
> AFAIK, the policy didn't change. but chances are that people who used to
> send directly have moved to a relay model. The PBL is used in many
> places. and some large sites use more restrictive lists anyway. so
> insisting on sending directly only causes grief, and things are mostly
> likely to "get worse".
>
> I personally use dnswl.org. so users who get blocked by the PBL are
> invited to submit their IP to dnswl.org.

A truly static IP address (with custom rDNS) on PBL can be removed by
the user; there is a web form with automated checks and a manual
review process. This typically shouldn't take more than a day or two.

If it's NOT static, why should it be whitelisted? When will it
change? Are checks done to ensure that it's still under control of
the dnswl.org. submitter?
-- 
Offlist mail to this address is discarded unless
"/dev/rob0" or "not-spam" is in Subject: header

Re: smtpd_recipient_restrictions evaluation question

[Sahil Tandon]

On Sun, 01 Nov 2009, Simon Morvan wrote:

[blah blah]

> And how am I supposed to send mail from my own mail server if I
> don't trust my ISP mail relay nor have $$$ to have a colo space and
> my own IP space ?
> 
> And, Stan, you refuse mails from my ISP mail relay... (the second
> biggest in France...)

I thought you said your previous message was your last on this topic?
Please, let's close this thread.

-- 
Sahil Tandon 

Re: smtpd_recipient_restrictions evaluation question

[mouss]

/dev/rob0 a écrit :
> On Sunday 01 November 2009 12:24:54 mouss wrote:
>> Simon Morvan a écrit :
>>> Le 30/10/2009 16:05, /dev/rob0 a écrit :
 [snip]

 Consider Zen here. It also incorporates the (not-quite-so) new PBL,
 which has been very effective here.
>>> The last time I tried it, Zen included too many legitimate users behind
>>> ADSL lines. The "Policy" behind PBL is a bit too restrictive. Maybe it
>>> changed, I'll give it another try.
>> AFAIK, the policy didn't change. but chances are that people who used to
>> send directly have moved to a relay model. The PBL is used in many
>> places. and some large sites use more restrictive lists anyway. so
>> insisting on sending directly only causes grief, and things are mostly
>> likely to "get worse".
>>
>> I personally use dnswl.org. so users who get blocked by the PBL are
>> invited to submit their IP to dnswl.org.
> 
> A truly static IP address (with custom rDNS) on PBL can be removed by
> the user; there is a web form with automated checks and a manual
> review process. This typically shouldn't take more than a day or two.
> 
> If it's NOT static, why should it be whitelisted? When will it
> change? Are checks done to ensure that it's still under control of
> the dnswl.org. submitter?

sorry, I was talking about static IPs. obviously, there is no point in
whitelisting a dynamic IP.

Re: smtpd_restrictions sanity check

[Alex]

Hi,

> smtpd_recipient_restrictions =
>        reject_non_fqdn_sender
>        reject_non_fqdn_recipient
>        permit_mynetworks
>        #permit_sasl_authenticated
>        reject_unauth_destination
>        #
>        reject_invalid_hostname
>        reject_non_fqdn_hostname
>        reject_unknown_sender_domain
>        #
>        check_client_access hash:/etc/postfix/client_checks
>        check_recipient_access pcre:/etc/postfix/relay_recips_checks
>        check_helo_access hash:/etc/postfix/helo_checks
>        check_sender_access hash:/etc/postfix/sender_checks
>        check_sender_access hash:/etc/postfix/disallow_my_domain
>        check_recipient_access pcre:/etc/postfix/recipient_checks
>        #
>        reject_rbl_client zen.spamhaus.org

How about pop-before-smtp? Would I add the check_client_access
immediately after permit_mynetworks above?

Will this configuration above prevent DSL or cable users without
reverse, only forward DNS from being accepted? I keep receiving the
following:

Nov  1 15:34:42 smtp01 postfix/smtpd[28620]: warning: 67.142.235.122:
hostname host6714200122235.direcway.com verification failed: Host not
found

The IP is in the popb4smtp db, but they still receive a relaying denied message:

Nov  1 14:32:44 smtp01 postfix/smtpd[23790]: reject: RCPT from
unknown[67.142.235.122]: 554 : Relay access denied;
from= to=

Thanks so much.
Best regards,
Alex

query re process of dealing with bounce

[Lists]

Hi all,

Setup is: we have a server that does the spam checking running 
MailScanner / Spamassassin and of course postfix


Mail is then delivered to a machine running MailEnable (where the boxes 
are held)


We had a situation where the MailEnable machine went down

*In the maillog of the server running postfix were:*
Oct 29 08:42:08 postfix/smtp[3619]: 37D5362E8A0: 
to=, 
relay=ipofmailenableserver[ipofmailenableserver]:25, delay=0.98, 
delays=0.93/0/0/0.05, dsn=5.7.1, status=bounced (host 
ipofmailenableserver[ipofmailenableserver] said: 550 5.7.1 Unable to 
relay for originallocalrecipi...@domain.co.nz (in reply to RCPT TO command))
Oct 29 08:42:08 postfix/cleanup[3449]: 2B11F62E8A2: 
message-id=<20091028194208.2b11f62e...@posfixserver.ourdomain>
Oct 29 08:42:08 postfix/qmgr[29235]: 2B11F62E8A2: from=<>, size=14216, 
nrcpt=1 (queue active)
Oct 29 08:42:08 postfix/bounce[4201]: 37D5362E8A0: sender non-delivery 
notification: 2B11F62E8A2

Oct 29 08:42:08 postfix/qmgr[29235]: 37D5362E8A0: removed
Oct 29 08:42:08 postfix/smtp[3619]: 2B11F62E8A2: 
to=, 
relay=ipofmailenableserver[ipofmailenableserver]:25, delay=0.05, 
delays=0/0/0/0.04, dsn=5.7.1, status=bounced (host 
ipofmailenableserver[ipofmailenableserver] said: 550 5.7.1 Unable to 
relay for originallocalsen...@domain.co.nz (in reply to RCPT TO command))

Oct 29 08:42:08 postfix/qmgr[29235]: 2B11F62E8A2: removed

Neither the original recipient or the original sender received 
notification that there was a problem or any form of bounce message. The 
original recipient also never received the email.


My question is what happened to the email and the bounces and how can I 
change the setup so that if this occured in the future (i.e. the spam 
checking server can't communicate with the mailenable server) mail does 
not disappear.


Thanks
Kate

Re: query re process of dealing with bounce

[Wietse Venema]

Lists:
> Hi all,
> 
> Setup is: we have a server that does the spam checking running 
> MailScanner / Spamassassin and of course postfix
> 
> Mail is then delivered to a machine running MailEnable (where the boxes 
> are held)
> 
> We had a situation where the MailEnable machine went down
> 
> *In the maillog of the server running postfix were:*
> Oct 29 08:42:08 postfix/smtp[3619]: 37D5362E8A0: 
> to=, 
> relay=ipofmailenableserver[ipofmailenableserver]:25, delay=0.98, 
> delays=0.93/0/0/0.05, dsn=5.7.1, status=bounced (host 
> ipofmailenableserver[ipofmailenableserver] said: 550 5.7.1 Unable to 
> relay for originallocalrecipi...@domain.co.nz (in reply to RCPT TO command))
> Oct 29 08:42:08 postfix/cleanup[3449]: 2B11F62E8A2: 
> message-id=<20091028194208.2b11f62e...@posfixserver.ourdomain>
> Oct 29 08:42:08 postfix/qmgr[29235]: 2B11F62E8A2: from=<>, size=14216, 
> nrcpt=1 (queue active)
> Oct 29 08:42:08 postfix/bounce[4201]: 37D5362E8A0: sender non-delivery 
> notification: 2B11F62E8A2
> Oct 29 08:42:08 postfix/qmgr[29235]: 37D5362E8A0: removed
> Oct 29 08:42:08 postfix/smtp[3619]: 2B11F62E8A2: 
> to=, 
> relay=ipofmailenableserver[ipofmailenableserver]:25, delay=0.05, 
> delays=0/0/0/0.04, dsn=5.7.1, status=bounced (host 
> ipofmailenableserver[ipofmailenableserver] said: 550 5.7.1 Unable to 
> relay for originallocalsen...@domain.co.nz (in reply to RCPT TO command))
> Oct 29 08:42:08 postfix/qmgr[29235]: 2B11F62E8A2: removed
> 
> Neither the original recipient or the original sender received 
> notification that there was a problem or any form of bounce message. The 
> original recipient also never received the email.

Indeed. The original message was rejected with a permanent error
("550 5.7.1 Unable to relay"), as was the non-delivery notification.

> My question is what happened to the email and the bounces and how can I 
> change the setup so that if this occured in the future (i.e. the spam 
> checking server can't communicate with the mailenable server) mail does 
> not disappear.

Configure the Mailenable system such that it doesn't reject mail
with a PERMANENT error for conditions that you don't consider
permanent.

You can configure the Postfix SMTP client to pretend that permanent
errors aren't permanent, but that introduces other risks.

Wietse

Re: smtpd_restrictions sanity check

[mouss]

Alex a écrit :
> Hi,
> 
>> smtpd_recipient_restrictions =
>>reject_non_fqdn_sender
>>reject_non_fqdn_recipient
>>permit_mynetworks
>>#permit_sasl_authenticated
>>reject_unauth_destination
>>#
>>reject_invalid_hostname
>>reject_non_fqdn_hostname
>>reject_unknown_sender_domain
>>#
>>check_client_access hash:/etc/postfix/client_checks
>>check_recipient_access pcre:/etc/postfix/relay_recips_checks
>>check_helo_access hash:/etc/postfix/helo_checks
>>check_sender_access hash:/etc/postfix/sender_checks
>>check_sender_access hash:/etc/postfix/disallow_my_domain
>>check_recipient_access pcre:/etc/postfix/recipient_checks
>>#
>>reject_rbl_client zen.spamhaus.org
> 
> How about pop-before-smtp? Would I add the check_client_access
> immediately after permit_mynetworks above?
> 

yes. but it is worth investing your time to implement SASL instead.

if you use pop before smtp, use a dedicated file and use it before
reject_unauth_destination (so that they can relay).

> Will this configuration above prevent DSL or cable users without
> reverse, only forward DNS from being accepted? I keep receiving the
> following:
> 
> Nov  1 15:34:42 smtp01 postfix/smtpd[28620]: warning: 67.142.235.122:
> hostname host6714200122235.direcway.com verification failed: Host not
> found
> 

this is only informational.

> The IP is in the popb4smtp db, but they still receive a relaying denied 
> message:
> 
> Nov  1 14:32:44 smtp01 postfix/smtpd[23790]: reject: RCPT from
> unknown[67.142.235.122]: 554 : Relay access denied;
> from= to=
> 

make sure the pop4smtp check comes before reject_unauth_destination. if
this is the case and you still see "Relay access denied", check  that
the IP of the client is in the map at the time of the check. and of
course, the map should return OK for the IP.