> that domain MUST NOT be listed in transport_maps.  Remove it.

> transport_maps overrides postfix internal routing decisions; you've
> told postfix to deliver that domain via smtp to the specified
> address, causing a loop.

Thank you indeed. Once I removed the domain from the transport table, I was able
to get this postfix configuration working.

Best regards!
tim

----- Original Message -----
From: "Noel Jones" <njones@...>
To: "Tim Dunphy" <bluethundr@...>, "postfix users"
<postfix-users@...>
Cc: "bluethundr" <bluethundr@...>
Sent: Monday, November 28, 2011 7:22:07 AM
Subject: Re: mail to domain bounced, to hostname accepted

On 11/27/2011 11:26 PM, Tim Dunphy wrote:
> Thanks Noel,
>
>  I tried altering the transport table I am using in the hopes of resolving the
situation.
>
>
>
> [root@mail ~]# grep CC2C124F9F /var/log/maillog
> Nov 28 00:21:36 mail postfix/smtpd[18192]: CC2C124F9F:
client=localhost[127.0.0.1]
> Nov 28 00:21:50 mail postfix/cleanup[18201]: CC2C124F9F:
message-id=<20111128052136.CC2C124F9F@...>
> Nov 28 00:21:50 mail postfix/qmgr[17871]: CC2C124F9F:
from=<bluethundr@...>, size=381, nrcpt=1 (queue active)
> Nov 28 00:21:50 mail postfix/smtp[18204]: CC2C124F9F:
to=<bluethundr@...>, relay=50.19.83.210[50.19.83.210]:25, delay=23,
delays=23/0.01/0.02/0, dsn=5.4.6, status=bounced (mail for [50.19.83.210] loops
back to myself)
> Nov 28 00:21:50 mail postfix/bounce[18207]: CC2C124F9F: sender non-delivery
notification: 1C48424FA1
>
>
> This is what the transport table looks like
>
> mysql> select * from transport;
> +----------------+---------------------+
> | domain         | transport           |
> +----------------+---------------------+
> | crispycode.com | smtp:[50.19.83.210] |
> +----------------+---------------------+
> 1 row in set (0.00 sec)

that domain MUST NOT be listed in transport_maps.  Remove it.

transport_maps overrides postfix internal routing decisions; you've
told postfix to deliver that domain via smtp to the specified
address, causing a loop.




   -- Noel Jones

Yes, understand the syntax/example mutt & nail that Jeroen &
Noel provided but sendmail.cf will need to be configured.

I got the following script which someone has tested working
on his postfix but I have a problem with RCPT TO:
(need someone to tell me how to obtain a valid address for RCPT TO)

Script:
=====

  {
     echo 'helo me'
     echo 'MAIL FROM:<you@...>'
     echo 'RCPT TO: <someone@...>'
     echo 'DATA'
     echo -e 'To:someone@...\nMIME-Version: 1.0
  (mime-construct 1.9)\nContent-Type:
  application/octet-stream\nContent-Transfer-Encoding: base64\n\n'
     cat myattachment.bin | openssl base64
     echo '.'
  } | nc smtp.mydomain.org 25



# telnet postfix_server 25

220 smtp.yy.zz ESMTP
helo me
250 servernm.yy.zz
MAIL FROM: <fromsms1@...>
250 Ok
RCPT TO: <mail@...>
550 <mail@...>: Recipient address rejected: User unknown in relay
recipient table
RCPT TO: <postfix@...>
550 <postfix@...>: Recipient address rejected: User unknown in relay
recipient table
DATA
554 Error: no valid recipients


How do I obtain a valid RCPT TO: address?


TIA
Roger

Just to add, I'm not allowed to start up sendmail (as it's hardened
for security reason), so editing sendmail.cf may not be an option.

So I certainly need a script/tool to do this forwarding to the relay
/postfix server


Roger

On Tue, Nov 29, 2011 at 11:15 AM, Roger Goh <gproger@...> wrote:

>
> Script:
> =====
>
>  {
>     echo 'helo me'
>     echo 'MAIL FROM:<you@...>'
>     echo 'RCPT TO: <someone@...>'
>     echo 'DATA'
>     echo -e 'To:someone@...\nMIME-Version: 1.0
>  (mime-construct 1.9)\nContent-Type:
>  application/octet-stream\nContent-Transfer-Encoding: base64\n\n'
>     cat myattachment.bin | openssl base64
>     echo '.'
>  } | nc smtp.mydomain.org 25
>
>
>
> # telnet postfix_server 25
>
> 220 smtp.yy.zz ESMTP
> helo me
> 250 servernm.yy.zz
> MAIL FROM: <fromsms1@...>
> 250 Ok
> RCPT TO: <mail@...>
> 550 <mail@...>: Recipient address rejected: User unknown in relay
> recipient table
> RCPT TO: <postfix@...>
> 550 <postfix@...>: Recipient address rejected: User unknown in relay
> recipient table
> DATA
> 554 Error: no valid recipients
>
>
> How do I obtain a valid RCPT TO: address?
>
>
> TIA
> Roger
>

Roger Goh:
> Just to add, I'm not allowed to start up sendmail (as it's hardened
> for security reason), so editing sendmail.cf may not be an option.
>
> So I certainly need a script/tool to do this forwarding to the relay
> /postfix server

Use the POSTFIX sendmail command.

	 Wietse

On 11/28/2011 05:45 PM, Noel Jones wrote:
> On 11/28/2011 1:04 PM, Wietse Venema wrote:
>> Alfredo Saldanha:
>>> Dear,
>>>
>>> I'd like to know if is there some way to disable automatic or manually
>>> Postfix filters in case of failure (overload) or something.
>>> I'm asking this because I was an incident where, under an overload of
>>> messages, I had problems with my mx performance (very high CPU load and
>>> memory usage) to deliver messages through filters header and body checks
>>> and also a check for a policy server.
>>> Somewhere in an overload, some messages were blocked, and would
>>> certainly "whitelisted" the Policy Server, but it was no longer
>>> responding to connections due to high load on the server processes.
>>> Then ask them, is possible turn off or divert messages from filters like
>>> cidr (check_client_access), body (body_checks) and header checks in the
>>> event of an overload of messages?
>> First of all, you must configure the system such that Postfix can
>> handle the load for the configured SMTP server process limit.  If
>> the default process limit (100) is too high for your system, reduce
>> the number.
>> http://www.postfix.org/postconf.5.html#default_process_limit
>>
>> You can stress test Postfix performance with the smtp-source utility
>> which is included with Postfix source code.
>> http://www.postfix.org/smtp-source.1.html
>>
>> Postfix has an overload-adaptive mechanism, but you should first
>> reduce your process limit until it is small enough that your system
>> can handle the load.
>> http://www.postfix.org/STRESS_README.html
>>
>>  Wietse
>
>
> Alfredo,
>
> In addition to what Wietse writes, I would encourage you to test
> your system to see exactly what is failing under high load.
>
> The check_client_access cidr table is unlikely to add more than a
> negligible amount of CPU usage, although a very large table (10's of
> thousands entries) might use quite a bit of memory.  Access table
> usage will show up in the memory and CPU usage of the smtpd
> processes.  Temporarily disable your access tables to measure the
> impact on the smtpd processes -- and note that most of the memory
> used by smtpd is shared between processes.
>
> header_checks and body_checks likewise should not use much ram or
> CPU unless you've configured an unreasonable number of checks.
> Remove entries that rarely or never match anything; limit the amount
> of data checked with body_checks by setting body_checks_size_limit
> to some reasonable number (the default 51200 should be reasonable
> for most sites).  These checks are run by the cleanup processes.
>
> Policy servers are a frequent source of performance issues.  Make
> sure yours isn't dying or timing out under heavy load.
>
> Finally, if your machine is swapping due to high memory use, either
> add RAM or reduce the postfix default_process_limit to manage peak
> memory use.
>
>
>
>    -- Noel Jones
>
Hi,

I have 6 instances of postfix here, one of each filter, transport maps, etc.

My first instance is "default_process_limit = 550", I supose that it was
not measured, but anyway, I'll make the stress test using postfix-source
to be sure how is the best configuration.

I send news.

Thank you guys,

Alfredo

To make Postfix highly-available, you mount the configuration, queue
and mailbox directories from a highly-available file store.

Then, you replace a broken Postfix server simply by mounting the
configuration, queue and mailbox directories on a different server
and giving that server the IP address of the broken server.

Making the IMAP server highly-available goes along similar lines.

	 Wietse

Hello,

Embarrassing question time...  was investigating use of port 587/submission in
addition to our usual 465/smtps, but I found that our server is already
listening on port 587.  ALL of the "submission" lines in master.cf are commented
out. 


Surely I just goofed something up, but I'm not sure where to start to track down
how postfix is listening on that port.  I can verify that it is definitely the
normal postfix instance because it's got our custom smtpd_banner and accepts
mail via our SASL authentication and whatnot.

What can I look at to investigate how submission listeners are being enabled?

Thank you

> Embarrassing question time...  was investigating use of port 587/submission in

> addition to our usual 465/smtps, but I found that our server is already
> listening on port 587.  ALL of the "submission" lines in master.cf are
> commented out. 
>
>
> Surely I just goofed something up, but I'm not sure where to start to track
> down how postfix is listening on that port.  I can verify that it is
definitely
> the normal postfix instance because it's got our custom smtpd_banner and
> accepts mail via our SASL authentication and whatnot.
>
> What can I look at to investigate how submission listeners are being enabled?

Even more embarrassing answer - that's what I get from testing using telnet from
a windows computer.  I guess the firewall software redirects port 587 to port 25
or some weird thing like that. 

Testing from elsewhere shows that in fact there is no submission listener
enabled.  Whew.

Sorry for the noise!

On 28/11/2011 20:16, Vincenzo Romano wrote:
> 2011/11/28 Viktor Dukhovni <postfix-users@...>:
>> On Mon, Nov 28, 2011 at 06:17:30PM +0100, Vincenzo Romano wrote:
>>
>>> 2011/11/28 Wietse Venema <wietse@...>:
>>>> Vincenzo Romano:
>>>>> The point is that postfix/smtp is not logging the Message-ID along
>>>>> with the other details it logs.
>>>>> Is there a way to ask postfix/smtp to log also the Message-ID?
>>>>
>>>> If you submit over port 25, then the SMTP server provides the queue
>>>> ID in the end-of-data reply.
>>>>
>>>> When you search the maillog file for this queue ID, then you will
>>>> find the Message-ID which is logged by the cleanup server.
>>>
>>> I'm using the sendmail tool.
>>
>> To track messages submitted via Sendmail, give each message a
>> globally unique application-assigned Message-Id. That message-id
>> is logged by cleanup(8) and the corresponding queue-id correlates
>> this log message with the other log entries for the same message.
>>
>> It seems this question has been re-asked and re-answered many times,
>> I think it is time to stop.
>
> Correct, Viktor.
> Once I'm said the queue ID is useful, then useless, then useful again.
> Now I know.
Te lo spiego in italiano, Viktor dice di assegnare un ID a livello APPLICATIVO
che sia univoco e che t renda tracciabile un messaggio.

Se vuoi che un ID VALIDO venga assegnato da Postfix devi inviare tramite la
porta 25, al contrario l'ID restituito da sendmail non puoi prenderlo in
considerazione perché è temporaneo.

In breve... usa smtp.

Spero ti averti chiarito la cosa.



--
Simone Caruso
IT Consultant
+39 349 65 90 805

Am 30.11.2011 11:39, schrieb Simone Caruso:
>> Correct, Viktor.
>> Once I'm said the queue ID is useful, then useless, then useful again.
>> Now I know.
> Te lo spiego in italiano, Viktor dice di assegnare un ID a livello APPLICATIVO
> che sia univoco e che t renda tracciabile un messaggio.
>
> Se vuoi che un ID VALIDO venga assegnato da Postfix devi inviare tramite la
> porta 25, al contrario l'ID restituito da sendmail non puoi prenderlo in
> considerazione perché è temporaneo.
>
> In breve... usa smtp.
> Spero ti averti chiarito la cosa.

what about speaking english in a public mailing-list instead switch
the language inside a running thread?

>
> what about speaking english in a public mailing-list instead switch
> the language inside a running thread?
>
Sorry I forgot to remove the list from 'Cc'; anyway i translated only Wietse and
Viktor emails without adding anything.

--
Simone Caruso
IT Consultant
+39 349 65 90 805

Hallo,

I would to like to enable SMTP authentication, as an option feature for our
users, but I have some questions before doing so.
1st: Is it possible to enable it, without Cyrus of Dovecot? I do not want to
install Cyrus of Dovecot on my gateway.
2nd: As far as I understand, there is an option to use SMTP auth for mail
submission only. Right?

Thanks,
Peter

On 11/30/2011 12:55 PM, Peter Tselios wrote:
> Hallo,
>
> I would to like to enable SMTP authentication, as an option feature for our
users, but I have some questions before doing so.
> 1st: Is it possible to enable it, without Cyrus of Dovecot? I do not want to
install Cyrus of Dovecot on my gateway.
You need either Cyrus SASL or Dovecot for Postfix to enable SMTP AUTH.

You do NOT need Cyrus IMAP or other services

> 2nd: As far as I understand, there is an option to use SMTP auth for mail
submission only. Right?
>

You choose how you want to use it.
Many administrators enforce (require) SASL on the submission port (587)
as well as options to use TLS.

Brian

Thank you Brian,

Sorry, to bug you, but, do you have any link to read how to enable the SMTP
Auth? My plan is to enable it (first for selected users and later for all users
(in the openLDAP). All "how-tos" I have found so far are with Cyrus or Dovecot.

P.



----- Áñ÷éêü ìÞíõìá -----
Áðï: Brian Evans - Postfix List <grknight@...>
Ðñïò: postfix-users@...
Êïéí.:
ÓôÜëèçêå: 8:08 ì.ì. ÔåôÜñôç, 30 Íïåìâñßïõ 2011
Èåìá: Re: SMTP Auth question

On 11/30/2011 12:55 PM, Peter Tselios wrote:
> Hallo,
>
> I would to like to enable SMTP authentication, as an option feature for our
users, but I have some questions before doing so.
> 1st: Is it possible to enable it, without Cyrus of Dovecot? I do not want to
install Cyrus of Dovecot on my gateway.
You need either Cyrus SASL or Dovecot for Postfix to enable SMTP AUTH.

You do NOT need Cyrus IMAP or other services

> 2nd: As far as I understand, there is an option to use SMTP auth for mail
submission only. Right?
>

You choose how you want to use it.
Many administrators enforce (require) SASL on the submission port (587)
as well as options to use TLS.

Brian

On 11/30/2011 1:13 PM, Peter Tselios wrote:
> Thank you Brian,
>
> Sorry, to bug you, but, do you have any link to read how to enable the SMTP
Auth? My plan is to enable it (first for selected users and later for all users
(in the openLDAP). All "how-tos" I have found so far are with Cyrus or Dovecot.
>
> P.

The Postfix documentation is quite extensive on this subject.
http://www.postfix.org/SASL_README.html#server_sasl

Brian

>
>
> ----- Áñ÷éêü ìÞíõìá -----
> Áðï: Brian Evans - Postfix List <grknight@...>
> Ðñïò: postfix-users@...
> Êïéí.:
> ÓôÜëèçêå: 8:08 ì.ì. ÔåôÜñôç, 30 Íïåìâñßïõ 2011
> Èåìá: Re: SMTP Auth question
>
> On 11/30/2011 12:55 PM, Peter Tselios wrote:
>> Hallo,
>>
>> I would to like to enable SMTP authentication, as an option feature for our
users, but I have some questions before doing so.
>> 1st: Is it possible to enable it, without Cyrus of Dovecot? I do not want to
install Cyrus of Dovecot on my gateway.
> You need either Cyrus SASL or Dovecot for Postfix to enable SMTP AUTH.
>
> You do NOT need Cyrus IMAP or other services
>
>> 2nd: As far as I understand, there is an option to use SMTP auth for mail
submission only. Right?
>>
> You choose how you want to use it.
> Many administrators enforce (require) SASL on the submission port (587)
> as well as options to use TLS.
>
> Brian
>

Hi All;

I am new to postfix.

I am using Fedora and I installed it using yum, also I was able to send email by
using the telnet method. I added one user in the linux using adduser command.

But when I tried to use outlook to send email, it failed !

First of all, I feel it is most probably related to the authentication, because
actually I am trying from my labtop and I used the username and password that I
built using adduser command.

Do I have to install and confiure saslauthd to be able to send email from my
outlook at my labtop? Or what could I am missing?

I did the needed configuration at the DNS and the MX record, and I routed it for
my mail server, also I added the mail server name in the main.cf file. And I was
able to send email using the telnet method as I said.

Any help?
Regards
Bilal

Am 30.11.2011 23:39, schrieb bilal ghayyad:
> I am new to postfix.
> I am using Fedora and I installed it using yum, also I was able to send email
> by using the telnet method. I added one user in the linux using adduser
command.
> But when I tried to use outlook to send email, it failed !
> First of all, I feel it is most probably related to the authentication,
because
> actually I am trying from my labtop and I used the username and password that
I
> built using adduser command.

new or not

without log-entries and any usefull information first "postconf -n"
nobody and nowhere can help you, independent of postfix

• DSN's for email sent to gmail work fine
• DSN's for email sent to yahoo work fine
• DSN's for email sent to a local account on my mail server work fine

There is one specific mail server though that I am not receiving "successful delivery" DSN's for, and I cannot figure out why. The following is the conversation log from my server to theirs:

Nov 30 16:39:19 bigbertha postfix/cleanup[18162]: 78861CCFF: warning: header Subject: asasddsad from c-98-197-129-225.hsd1.tx.comcast.net[98.197.129.225]; from=<rjones@...> to=<redacted> proto=ESMTP helo=<[192.168.2.3]>
Nov 30 16:39:19 bigbertha postfix/qmgr[16356]: 78861CCFF: from=<rjones@...>, size=805, nrcpt=1 (queue active)
Nov 30 16:39:19 bigbertha postfix/smtpd[18337]: disconnect from c-98-197-129-225.hsd1.tx.comcast.net[98.197.129.225]
Nov 30 16:39:21 bigbertha postfix/smtp[18341]: 78861CCFF: to=<redacted>, relay=redacted[redacted]:25, delay=2.5, delays=0.18/0/0.43/1.9, dsn=2.0.0, status=sent (250 +OK message queued for delivery.)
Nov 30 16:39:21 bigbertha postfix/qmgr[16356]: 78861CCFF: removed

Given that the remote mail server is returning a "250" status, why would I not get a successful DSN? The return code looks exactly the same as mail to a test yahoo account that I *did* get a successful DSN generated for:

Nov 30 16:38:28 bigbertha postfix/cleanup[18162]: 17F73CCFF: warning: header Subject: test from c-98-197-129-225.hsd1.tx.comcast.net[98.197.129.225]; from=<rjones@...> to=<redacted> proto=ESMTP helo=<[192.168.2.3]>
Nov 30 16:38:28 bigbertha postfix/qmgr[16356]: 17F73CCFF: from=<rjones@...>, size=785, nrcpt=1 (queue active)
Nov 30 16:38:30 bigbertha postfix/smtp[18341]: 17F73CCFF: to=<redacted>, relay=mta5.am0.yahoodns.net[67.195.168.31]:25, delay=2.2, delays=0.16/0.01/0.28/1.7, dsn=2.0.0, status=sent (250 ok dirdel)
Nov 30 16:38:30 bigbertha postfix/bounce[18342]: 17F73CCFF: sender delivery status notification: 3827D74091
Nov 30 16:38:30 bigbertha postfix/qmgr[16356]: 17F73CCFF: removed

I have a feeling I am misunderstanding what communication takes places behind the scenes when a DSN is requested. If someone could shed some light on it for me, that'd be awesome :)

Hi *,

My google-foo is failing me at this point, so I turn to you all. I am using a standard Postfix setup and am sending messages via Thunderbird. I am choosing under the Options menu "Delivery Status Notification". The results:

• DSN's for email sent to gmail work fine
• DSN's for email sent to yahoo work fine
• DSN's for email sent to a local account on my mail server work fine

There is one specific mail server though that I am not receiving "successful delivery" DSN's for, and I cannot figure out why. The following is the conversation log from my server to theirs:

Nov 30 16:39:19 bigbertha postfix/cleanup[18162]: 78861CCFF: warning: header Subject: asasddsad from c-98-197-129-225.hsd1.tx.comcast.net[98.197.129.225]; from=<rjones@...> to=<redacted> proto=ESMTP helo=<[192.168.2.3]>
Nov 30 16:39:19 bigbertha postfix/qmgr[16356]: 78861CCFF: from=<rjones@...>, size=805, nrcpt=1 (queue active)
Nov 30 16:39:19 bigbertha postfix/smtpd[18337]: disconnect from c-98-197-129-225.hsd1.tx.comcast.net[98.197.129.225]
Nov 30 16:39:21 bigbertha postfix/smtp[18341]: 78861CCFF: to=<redacted>, relay=redacted[redacted]:25, delay=2.5, delays=0.18/0/0.43/1.9, dsn=2.0.0, status=sent (250 +OK message queued for delivery.)
Nov 30 16:39:21 bigbertha postfix/qmgr[16356]: 78861CCFF: removed

Given that the remote mail server is returning a "250" status, why would I not get a successful DSN? The return code looks exactly the same as mail to a test yahoo account that I *did* get a successful DSN generated for:

Nov 30 16:38:28 bigbertha postfix/cleanup[18162]: 17F73CCFF: warning: header Subject: test from c-98-197-129-225.hsd1.tx.comcast.net[98.197.129.225]; from=<rjones@...> to=<redacted> proto=ESMTP helo=<[192.168.2.3]>
Nov 30 16:38:28 bigbertha postfix/qmgr[16356]: 17F73CCFF: from=<rjones@...>, size=785, nrcpt=1 (queue active)
Nov 30 16:38:30 bigbertha postfix/smtp[18341]: 17F73CCFF: to=<redacted>, relay=mta5.am0.yahoodns.net[67.195.168.31]:25, delay=2.2, delays=0.16/0.01/0.28/1.7, dsn=2.0.0, status=sent (250 ok dirdel)
Nov 30 16:38:30 bigbertha postfix/bounce[18342]: 17F73CCFF: sender delivery status notification: 3827D74091
Nov 30 16:38:30 bigbertha postfix/qmgr[16356]: 17F73CCFF: removed

I have a feeling I am misunderstanding what communication takes places behind the scenes when a DSN is requested. If someone could shed some light on it for me, that'd be awesome :)

Russell Jones:
> <html>
>   <head>
>     <meta content="text/html; charset=ISO-8859-1"
>       http-equiv="Content-Type">
>   </head>
>   <body bgcolor="#FFFFFF" text="#000000">
>     Nevermind, I have finally found an article that explains DSN from
>     behind the scenes. It is quite different than just a standard "250
>     OK" status message of course. Article was written in 1997
>     apparently, but still helpful
>     (<a class="moz-txt-link-freetext"
href="http://email.about.com/library/weekly/aa082597.htm">http://email.about.com\
/library/weekly/aa082597.htm</a>)<br>
>     <br>
>     On to a different question, does Postfix have any features I am
>     unaware of that can still generate a "success" message if the remote
>     mail server responds with a "250"?<br>

Postfix will send DSN "success" notification when the remote server
does NOT announce DSN support.

If the server announces DSN support, then Postfix is no longer
responsible for sending DSN "success" notification.

	 Wietse

Hi Wietse,

Thanks! That's different from what I read in that article then...
according to that article the remote mail server needs to support DSN as
well for the reports to be generated.

If what you are saying is correct, how can I go about diagnosing why I
am not receiving DSN "success" notices when mail is sent to this one
specific mail server I provided in my log output?


Russell

On 11/30/2011 5:50 PM, Wietse Venema wrote:
> Russell Jones:
>> <html>
>>    <head>
>>      <meta content="text/html; charset=ISO-8859-1"
>>        http-equiv="Content-Type">
>>    </head>
>>    <body bgcolor="#FFFFFF" text="#000000">
>>      Nevermind, I have finally found an article that explains DSN from
>>      behind the scenes. It is quite different than just a standard "250
>>      OK" status message of course. Article was written in 1997
>>      apparently, but still helpful
>>      (<a class="moz-txt-link-freetext"
href="http://email.about.com/library/weekly/aa082597.htm">http://email.about.com\
/library/weekly/aa082597.htm</a>)<br>
>>      <br>
>>      On to a different question, does Postfix have any features I am
>>      unaware of that can still generate a "success" message if the remote
>>      mail server responds with a "250"?<br>
> Postfix will send DSN "success" notification when the remote server
> does NOT announce DSN support.
>
> If the server announces DSN support, then Postfix is no longer
> responsible for sending DSN "success" notification.
>
>  Wietse
>

Russell Jones:
> Hi Wietse,
>
> Thanks! That's different from what I read in that article then...
> according to that article the remote mail server needs to support DSN as
> well for the reports to be generated.

Per RFC 3461..3464, Postfix sends DSN "relayed" (not success) if
the remote server does not announce DSN support. The RFCs are
public documents, so you don't have to take my word for it.

If the remote server announces DSN support, and you receive no
"success" or "relayed" notification, then some remote system does
not implement DSN correctly.

Debugging remote SMTP servers is outside the scope of Postfix
support.

	 Wietse

Ah that makes sense!

This problematic mail server does announce DSN when you telnet to it,
while Google, Yahoo etc do not announce DSN support.

Thanks for your help. Final question (hopefully), is there a way to
ignore DSN announcements from remote servers and just treat them as if
they don't support DSN, that way I can get the relay/success emails I
need? I've read through the DSN readme
(http://www.postfix.org/DSN_README.html) and it doesn't appear to cover
that (if it's an option). I also searched for "dsn" on
(http://www.postfix.org/postconf.5.html) for main.cf options for doing
this with no luck.


On 11/30/2011 6:00 PM, Wietse Venema wrote:
> Russell Jones:
>> Hi Wietse,
>>
>> Thanks! That's different from what I read in that article then...
>> according to that article the remote mail server needs to support DSN as
>> well for the reports to be generated.
> Per RFC 3461..3464, Postfix sends DSN "relayed" (not success) if
> the remote server does not announce DSN support. The RFCs are
> public documents, so you don't have to take my word for it.
>
> If the remote server announces DSN support, and you receive no
> "success" or "relayed" notification, then some remote system does
> not implement DSN correctly.
>
> Debugging remote SMTP servers is outside the scope of Postfix
> support.
>
>  Wietse
>

Russell Jones:
> Ah that makes sense!
>
> This problematic mail server does announce DSN when you telnet to it,
> while Google, Yahoo etc do not announce DSN support.
>
> Thanks for your help. Final question (hopefully), is there a way to
> ignore DSN announcements from remote servers and just treat them as if
> they don't support DSN, that way I can get the relay/success emails I
> need? I've read through the DSN readme
> (http://www.postfix.org/DSN_README.html) and it doesn't appear to cover
> that (if it's an option). I also searched for "dsn" on
> (http://www.postfix.org/postconf.5.html) for main.cf options for doing
> this with no luck.

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

(that's smtp, not smtpd).

Or, more radically,
http://www.postfix.org/postconf.5.html#smtp_discard_ehlo_keywords

	 Wietse

Thanks! Just got it working as intended =)

Nov 30 18:33:04 bigbertha postfix/smtp[22632]: discarding EHLO keywords: DSN



On 11/30/2011 6:33 PM, Wietse Venema wrote:
> Russell Jones:
>> Ah that makes sense!
>>
>> This problematic mail server does announce DSN when you telnet to it,
>> while Google, Yahoo etc do not announce DSN support.
>>
>> Thanks for your help. Final question (hopefully), is there a way to
>> ignore DSN announcements from remote servers and just treat them as if
>> they don't support DSN, that way I can get the relay/success emails I
>> need? I've read through the DSN readme
>> (http://www.postfix.org/DSN_README.html) and it doesn't appear to cover
>> that (if it's an option). I also searched for "dsn" on
>> (http://www.postfix.org/postconf.5.html) for main.cf options for doing
>> this with no luck.
> http://www.postfix.org/postconf.5.html#smtp_discard_ehlo_keyword_address_maps
>
> (that's smtp, not smtpd).
>
> Or, more radically,
> http://www.postfix.org/postconf.5.html#smtp_discard_ehlo_keywords
>
>  Wietse
>

Hello,


I am running a mail relay that forwards all mail from some "management
network" to a corporate  MTA.  For security reasons, my gateway is configured to
relay mail only to internal destination addresses (users@...).  There
are a few
exceptions and all "external" addresses must be whitelisted.

Pretty basic setup -
smtpd_recipient_restrictions = check_recipient_access
hash:/usr/local/etc/postfix/access,
                                reject_unauth_destination, permit

/usr/local/etc/postfix/access:
user1@...  OK
user2@...  OK


It did what I needed so far. Now there is a new host ABC that would need
to send  mail to a large number of external addresses and whitelist management
becomes a pain.


I am looking for a way to create an exception for check_recipient_access,
ideally, IP-based.
Basically, I would like to allow IP of ABC to freely send mail outside and to
enforce check_recipient_access
for all other hosts.

I checked some smtpd_restriction_classes examples, but did find anything
similar.

Any ideas?

Thank you.



--
.signature: No such file or directory

On Wed, Nov 30, 2011 at 08:38:13PM -0500, Vladimir Parkhaev wrote:

Augment this:

> smtpd_recipient_restrictions =
>  check_recipient_access hash:/usr/local/etc/postfix/access,
>  reject_unauth_destination,
>  permit

As follows (and avoid using "access", name each table after its
specific role):

main.cf:
   cidr = cidr:${config_directory}/
   indexed = ${default_database_type}:${config_directory}/
   #
   smtpd_recipient_restrictions =
	 check_client_access ${cidr}trusted-clients,
	 check_recipient_access ${indexed}rcpt-whitelist,
	 reject_unauth_destination,
	 permit

/usr/local/etc/postfix/rcpt-whitelist: (postmap rcpt-whitelist when changed)
   user1@...  OK
   user2@...  OK

/usr/local/etc/postfix/rcpt-whitelist: (no postmap for cidr tables)
   192.0.2.1 permit

--
	 Viktor.

Am 01.12.2011 08:35, schrieb DN Singh:
> Hello Group,
>
> I am trying some extra configuration for postfix where it would mark
> some destinations as undeliverable. I have found that there are some
> destinations, start deferring the mails (may be greylisting) for a
> particular period of time (times ranging from 1min to 4hrs), and after
> the time window is over, they accept mails properly. So, I would like to
> configure per-destination dead time limit, where Postfix would not
> attempt any delivery at all to a destination for the mentioned time.
>
> I tried configuring backoff-time, but it only comes into picture after
> first attempt, which will get deferred, during time the destination is
> differing. Next, I found
> "default_destination_concurrency_failed_cohort_limit", but I was unable
> to find to time for which it will remain dead. I know this is transport
> configurable, so I can configure different time limits for different
> destinations. This is because, I do not want any delivery attempts
> during the time when a destination is marked dead.
>
> Is this possible? If yes, then how?
>
> Thanks.
> DN Singh

perhaps put some kind of scripted hold on them
if they are always the same

or use ideas from

http://www.postfix.org/QSHAPE_README.html#backlog

Postfix version 2.5 and later:

     In master.cf set up a dedicated clone of the "smtp" transport for
the problem destination. In the example below we call it "slow".

     In main.cf configure a short delay between deliveries to the same
destination.

     /etc/postfix/main.cf:
         transport_maps = hash:/etc/postfix/transport
         slow_destination_rate_delay = 1
         slow_destination_concurrency_failed_cohort_limit = 100

     /etc/postfix/transport:
         example.com  slow:

     /etc/postfix/master.cf:
         # service type  private unpriv  chroot  wakeup  maxproc command
         slow      unix     -       -       n       -       -    smtp

See also the documentation for default_destination_rate_delay.

This solution forces the Postfix smtp(8) client to wait for
$slow_destination_rate_delay seconds between deliveries to the same
destination.

IMPORTANT!! The large slow_destination_concurrency_failed_cohort_limit
value is needed. This prevents Postfix from deferring all mail for the
same destination after only one connection or handshake error (the
reason for this is that non-zero slow_destination_rate_delay forces a
per-destination concurrency of 1).


--
Best Regards

MfG Robert Schetterer

Germany/Munich/Bavaria