Use relayhost and also DNS based routing

[Ram]

I have a postfix relay server that sends all mails to a relayhost.
Problem is that some domains , whose MX is all same, are  not accepting 
mails from that relayhost for now.


Until that issue is resolved I want to route all such domains  mails ( 
where MX is pointing to a particular host ) via a different network.

I dont have a list of all such domains , only the MX host is known

Can there be any such configuration in postfix


Thanks
Ram

Re: relay access denied question

[Noel Jones]

On 5/3/2016 4:05 PM, Chris Adams wrote:
> Hello all,
> 
>  
> 
> I recently rebuilt a server for use with Mailman and Postfix. I have
> the server running, Mailman and Postfix installed. I am using
> Postfix 2.10.1.   I copied the main.cf file over from the old server
> to the new server.
> 
>  
> 
> When I post a message to one of the Mailman lists, I encounter an
> error related to Postfix and I can’t quite figure out what setting
> in main.cf is causing this. It looks like all messages are being
> handled this way. I am wondering what is different in this new setup
> that would cause this.
> 
>  
> 
> May  3 16:59:58 mailmanserver postfix/smtpd[18060]: NOQUEUE: reject:
> RCPT from localhost[::1]: 454 4.7.1 : Relay
> access denied; from=
> to= proto=ESMTP helo=
> 
>  
> 
> I can provide output of postconf –n if requested.
> 
>  
> 
> Many thanks.
> 

Perhaps you forgot to read the RELEASE_NOTES.
See the "Major changes - relay safety" section

ftp://mirrors.loonybin.net/pub/postfix/official/postfix-2.10.9.RELEASE_NOTES

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

Also note that 2.10.1 is pretty old.  For a new server, consider
using a more current version.


  -- Noel Jones

relay access denied question

[Chris Adams]

Hello all,

I recently rebuilt a server for use with Mailman and Postfix. I have the server 
running, Mailman and Postfix installed. I am using Postfix 2.10.1.   I copied 
the main.cf file over from the old server to the new server.

When I post a message to one of the Mailman lists, I encounter an error related 
to Postfix and I can't quite figure out what setting in main.cf is causing 
this. It looks like all messages are being handled this way. I am wondering 
what is different in this new setup that would cause this.

May  3 16:59:58 mailmanserver postfix/smtpd[18060]: NOQUEUE: reject: RCPT from 
localhost[::1]: 454 4.7.1 : Relay access denied; 
from= to= proto=ESMTP 
helo=

I can provide output of postconf -n if requested.

Many thanks.

Re: Best practice?

[Noel Jones]

On 5/3/2016 12:38 PM, John Allen wrote:
> Is it better to add restrictions/tests to the appropriate section or
> is it better to place then all under one, for example everything to
> do with sender (check_sender_access...) with
> smtpd_sender_restrictions. Similar setup for all the other sections.

There is no one right way.

> 
> I only ask because in reading various how-to, etc., I find there
> seems to be two schools of thought
> 1) lump just about everything under one restriction "class"
> (usually smtpd_recipient_...).
> 2) place the test with the appropriate class.
> I understand that with "smtpd_delay_reject=yes" there isn't much
> difference, does breaking them up have any detrimental effects?

For most common rules, it's probably easier to put everything under
one section.  Most people feel this gives them a good mental picture
of what's happening, and makes whitelisting straightforward.

Some folks visualize it better splitting it up.  That's OK too.
More care must be taken with whitelisting when you use multiple
sections.  It's possible to do more complex rules when splitting up
the sections, but this is seldom a requirement.


> 
> 
> 
> Just to make sure I am think correctly

Close enough.




  -- Noel Jones

Re: Is this sane submission setup?

[Charles Marcus]

On 4/29/2016 9:51 AM, Alice Wonder  wrote:
> What I'm trying to have it do is define the blog hosts (there are three 
> or four of them, with about 20 different domain names on each host) can 
> connect over 587 with authentication but that even with the right uname 
> / password, connection is refused from any other host.

For that you use client_restrictions... permit only the ones you want to
allow, reject all others...

Best practice?

[John Allen]

Is it better to add restrictions/tests to the appropriate section or is 
it better to place then all under one, for example everything to do with 
sender (check_sender_access...) with smtpd_sender_restrictions. Similar 
setup for all the other sections.


I only ask because in reading various how-to, etc., I find there seems 
to be two schools of thought
1) lump just about everything under one restriction "class" 
(usually smtpd_recipient_...).

2) place the test with the appropriate class.
I understand that with "smtpd_delay_reject=yes" there isn't much 
difference, does breaking them up have any detrimental effects?




Just to make sure I am think correctly

client: => ? not quite sure, but it seems to be validation of the 
physical connection,  (ip, hostname etc, connecting MTA)


etrn: => ?

helo: => MTA to MTA hand shake

To: => recipient

relay: => control over what if any relaying of mail is allowed

From: => sender

data: => control how the data, /the email/, is handled

Re: Logs indicate high speed sending despite custom transport settings

[Wietse Venema]

Steven Peterson:
> > The below settings are queue-manager settings and must be made in
> > main.cf, not master.cf.
> 
> Thanks, moving those settings to main.cf was the charm.  I have not been
> able to find a reference as to which parameters can be set using the -o
> switch by the transport in master.cf, and which must be in main.cf. Is
> there such a page?

http://www.postfix.org/postconf.5.html#transport_destination_concurrency_limit
http://www.postfix.org/postconf.5.html#default_destination_concurrency_limit

Wietse

Re: Logs indicate high speed sending despite custom transport settings

[Viktor Dukhovni]

On Tue, May 03, 2016 at 12:20:58PM -0400, Steven Peterson wrote:

> > The below settings are queue-manager settings and must be made in
> > main.cf, not master.cf.
> 
> Thanks, moving those settings to main.cf was the charm.  I have not been
> able to find a reference as to which parameters can be set using the -o
> switch by the transport in master.cf, and which must be in main.cf. Is
> there such a page?

The manpage for each daemon documents which parameters it implements.
See qmgr(8), smtp(8), ...

Also by the time a delivery agent is given a message to deliver it
is clearly too late to do rate controls.  Rate controls belong in
the scheduler, which in Postfix is qmgr(8).

-- 
Viktor.

Re: Logs indicate high speed sending despite custom transport settings

[Steven Peterson]

> The below settings are queue-manager settings and must be made in
> main.cf, not master.cf.

Thanks, moving those settings to main.cf was the charm.  I have not been
able to find a reference as to which parameters can be set using the -o
switch by the transport in master.cf, and which must be in main.cf. Is
there such a page?

> You really need to contact comcast.net and get whitelisted (if
> you're sending email that comcast users want and have signed up
> for).  If you're sending unsolicited bulk email to comcast users,
> I'm afraid that comcast has every right and incentive to make your
> job as difficult as possible.

We have contacted comcast and they maintain that for new sending IP
addresses, they follow a strict throttling regimen until the IP has
established its reputation.  They estimate it will take a few weeks for a
new IP to reach their unqualified good graces.

Best, Steve


On Tue, May 3, 2016 at 11:29 AM, Viktor Dukhovni  wrote:

> On Tue, May 03, 2016 at 03:25:26PM +, Viktor Dukhovni wrote:
> > On Tue, May 03, 2016 at 10:57:31AM -0400, Steven Peterson wrote:
> >
> > > $>cat /etc/postfix-br/master.cf
> > > ...
> > > acct_client1unix  -   -  n   -   -   smtp
> > >   -o syslog_name=br-client1
> > >   -o smtp_bind_address=185.94.24.84
> > >   -o smtp_helo_name=news.client1.org
> >
> > The below settings are queue-manager settings and must be made in
> > main.cf, not master.cf.
> >
> > >   -o acct_client1_destination_concurrency_limit=2
> > >   -o acct_client1_destination_recipient_limit=5
> > >   -o acct_client1_destination_rate_delay=1s
> > >   -o initial_destination_concurrency=2
> > >   -o acct_client1_destination_concurrency_failed_cohort_limit=200
>
> Also note that rate delay forces the concurrency to 1, so you can't
> go faster than 1 message per second with rate delays.
>
> You really need to contact comcast.net and get whitelisted (if
> you're sending email that comcast users want and have signed up
> for).  If you're sending unsolicited bulk email to comcast users,
> I'm afraid that comcast has every right and incentive to make your
> job as difficult as possible.
>
> --
> Viktor.
>

Re: Logs indicate high speed sending despite custom transport settings

[Viktor Dukhovni]

On Tue, May 03, 2016 at 03:25:26PM +, Viktor Dukhovni wrote:
> On Tue, May 03, 2016 at 10:57:31AM -0400, Steven Peterson wrote:
> 
> > $>cat /etc/postfix-br/master.cf
> > ...
> > acct_client1unix  -   -  n   -   -   smtp
> >   -o syslog_name=br-client1
> >   -o smtp_bind_address=185.94.24.84
> >   -o smtp_helo_name=news.client1.org
> 
> The below settings are queue-manager settings and must be made in
> main.cf, not master.cf.
> 
> >   -o acct_client1_destination_concurrency_limit=2
> >   -o acct_client1_destination_recipient_limit=5
> >   -o acct_client1_destination_rate_delay=1s
> >   -o initial_destination_concurrency=2
> >   -o acct_client1_destination_concurrency_failed_cohort_limit=200

Also note that rate delay forces the concurrency to 1, so you can't
go faster than 1 message per second with rate delays.

You really need to contact comcast.net and get whitelisted (if
you're sending email that comcast users want and have signed up
for).  If you're sending unsolicited bulk email to comcast users,
I'm afraid that comcast has every right and incentive to make your
job as difficult as possible.

-- 
Viktor.

Re: Logs indicate high speed sending despite custom transport settings

[Viktor Dukhovni]

On Tue, May 03, 2016 at 10:57:31AM -0400, Steven Peterson wrote:

> $>cat /etc/postfix-br/master.cf
> ...
> acct_client1unix  -   -  n   -   -   smtp
>   -o syslog_name=br-client1
>   -o smtp_bind_address=185.94.24.84
>   -o smtp_helo_name=news.client1.org

The below settings are queue-manager settings and must be made in
main.cf, not master.cf.

>   -o acct_client1_destination_concurrency_limit=2
>   -o acct_client1_destination_recipient_limit=5
>   -o acct_client1_destination_rate_delay=1s
>   -o initial_destination_concurrency=2
>   -o acct_client1_destination_concurrency_failed_cohort_limit=200

-- 
Viktor.

Logs indicate high speed sending despite custom transport settings

[Steven Peterson]

Dear Postfix Experts

Thanks to everyone's aid in improving my customer transport settings to the
comcast.net domain. Our backlog is going down steadily.

But I'm afraid that despite my efforts to gently spoon feed messages to
sensitive domains such as comcast.net, the logs indicate I am still
pounding them with messages until we are throttled.  Based on my custom
transport settings, I would expect that they would only be sent two
messages per second because I specify only two concurrent connections to
any one domain and messages should be spaced 1 second apart in the custom
transport (acct_client1).  However, when I look at the logs, it looks like
we are send over 50 messages in a 3-second period.  Are the logs correct as
to the time?  If so, how would I correctly slow down the broadcast speed?

Best, Steve



$> postconf -c /etc/postfix-br -n

authorized_submit_users =
command_directory = /usr/sbin
config_directory = /etc/postfix-br
daemon_directory = /usr/libexec/postfix
data_directory = /var/lib/postfix-br
debug_peer_level = 2
debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin ddd
$daemon_directory/$process_name $process_id & sleep 5
default_destination_concurrency_limit = 20
default_process_limit = 230
fast_flush_domains = mydomain.net
html_directory = no
inet_protocols = ipv4
mail_owner = postfix
mailq_path = /usr/bin/mailq.postfix
manpage_directory = /usr/share/man
master_service_disable =
maximal_queue_lifetime = 5d
minimal_backoff_time = 300s
multi_instance_enable = yes
multi_instance_name = postfix-br
newaliases_path = /usr/bin/newaliases.postfix
queue_directory = /var/spool/postfix-br
readme_directory = /usr/share/doc/postfix-2.6.6/README_FILES
sample_directory = /usr/share/doc/postfix-2.6.6/samples
sender_dependent_default_transport_maps =
hash:/etc/postfix-br/sender_transport.txt
sendmail_path = /usr/sbin/sendmail.postfix
setgid_group = postdrop
smtp_bind_address = 198.64.153.201
smtp_helo_timeout = 100s
syslog_name = br-shared
unknown_local_recipient_reject_code = 550
virtual_alias_maps =
hash:/var/custom/virtual.txt,regexp:/var/custom/virtual_listpilot.regexp



$>cat /etc/postfix-br/master.cf
...
acct_client1unix  -   -  n   -   -   smtp
  -o syslog_name=br-client1
  -o smtp_bind_address=185.94.24.84
  -o smtp_helo_name=news.client1.org
  -o acct_client1_destination_concurrency_limit=2
  -o acct_client1_destination_recipient_limit=5
  -o acct_client1_destination_rate_delay=1s
  -o initial_destination_concurrency=2
  -o acct_client1_destination_concurrency_failed_cohort_limit=200
...


---
$> grep "br-client1.*@comcast.net" /var/logs/maillog
  (NOTE: Logs indicate sent 50 messages in 3 seconds to comcast.net)

  ...
May  3 01:46:55 mail4 br-client1/smtp[31935]: 2DC48CF0842: to=<
ardelljeffer...@comcast.net>, relay=mx1.comcast.net[96.114.157.80]:25,
delay=1041, delays=1039/1/0.22/0.81, dsn=2.0.0, status=sent (250 2.0.0
phms1s03B1ors0201hms63 mail accepted for delivery)
May  3 01:46:55 mail4 br-client1/smtp[31969]: 20750CF0230: to=<
egl...@comcast.net>, relay=mx2.comcast.net[68.87.20.5]:25, conn_use=3,
delay=1116, delays=1114/1.6/0.05/0.27, dsn=2.0.0, status=sent (250 2.0.0
phms1s01M1ors0201hmtGU mail accepted for delivery)
May  3 01:46:55 mail4 br-client1/smtp[32046]: 27795CF061F: to=<
dsdu...@comcast.net>, relay=mx2.comcast.net[68.87.20.5]:25, delay=1072,
delays=1070/1.2/0.24/0.59, dsn=2.0.0, status=sent (250 2.0.0
phms1s04U1ors0201hmsdj mail accepted for delivery)
May  3 01:46:55 mail4 br-client1/smtp[31966]: 23B98CEFCF6: to=<
chughe...@comcast.net>, relay=mx2.comcast.net[68.87.20.5]:25, delay=1170,
delays=1168/1.2/0.33/0.5, dsn=2.0.0, status=sent (250 2.0.0
phms1s06X1ors0201hmsRl mail accepted for delivery)
May  3 01:46:55 mail4 br-client1/smtp[32061]: 2F20ECEFE54: to=<
cinseym...@comcast.net>, relay=mx1.comcast.net[96.114.157.80]:25,
delay=1158, delays=1156/1.4/0.21/0.45, dsn=2.0.0, status=sent (250 2.0.0
phms1s05S1ors0201hmsJs mail accepted for delivery)
May  3 01:46:55 mail4 br-client1/smtp[31934]: 2E606CF0FA5: to=<
dave_di...@comcast.net>, relay=mx1.comcast.net[96.114.157.80]:25,
conn_use=2, delay=934, delays=932/1.5/0.06/0.49, dsn=2.0.0, status=sent
(250 2.0.0 phms1s0131ors0201hmsEU mail accepted for delivery)
May  3 01:46:55 mail4 br-client1/smtp[32067]: 2ACB0CEA256: to=<
vetas...@comcast.net>, relay=mx1.comcast.net[96.114.157.80]:25, delay=1167,
delays=1165/1.4/0.23/0.59, dsn=2.0.0, status=sent (250 2.0.0
phms1s0791ors0201hmsRM mail accepted for delivery)
May  3 01:46:55 mail4 br-client1/smtp[31991]: 2470ACEFFFA: to=<
alike...@comcast.net>, relay=mx1.comcast.net[96.114.157.80]:25, conn_use=2,
delay=1139, delays=1137/1.4/0.07/0.64, dsn=2.0.0, status=sent (250 2.0.0
phms1s00H1ors0201hmsR9 mail accepted for delivery)
May  3 01:46:55 mail4 br-client1/smtp[31988]: 25C2ACF0872: to=<
artfourn...@comcast.net>, relay=mx1.comcast.net[96.114.157.80]:2

Re: No logs between Apr 25 - 27. What happened?

[Sven Schwedas]

On 2016-05-03 15:54, li...@lazygranch.com wrote:
> ‎My maillog doesn't rotate. Is this an option in postfix? Trawling the
> interwebs, I find maillog rotation handled outside postfix with custom
> scripts.

Yes, normally by logrotate. Most distributions have rotation of
mail.info in their shipped configurations and do it by default.

(If you have /var/log/mail.info at all, you're using syslog, not
systemd-journald.)

> *From: *Matthias Andree
> *Sent: *Monday, May 2, 2016 11:57 PM
> *To: *tswmmeejsdad .; postfix-users@postfix.org
> *Subject: *Re: No logs between Apr 25 - 27. What happened?
> 
> 
> Am 3. Mai 2016 06:15:55 MESZ, schrieb "tswmmeejsdad ."
> :
> 
> Hi All,
> 
> Anyone know what I should check for to determine why logging to
> /var/log/mail stopped suddenly between Apr 25-27? I can see mail
> logs before and after those dates but nothing was logged between
> those dates. Mail was working fine else we would have had customers
> call up during those three days.
> 
> Thanks.
> 
> Andy
> 
> 
> Check for:
> - Syslog crashes
> - Botched log rotation especially with compression vs. Signals
> (logrotate, newsyslog)
> - Systemd/journal* malfunction on modern Linux
> - File system issues (skipped fsck after a crash)
> - Memory and other hw issues
> 

-- 
Mit freundlichen Grüßen, / Best Regards,
Sven Schwedas
Systemadministrator
TAO Beratungs- und Management GmbH | Lendplatz 45 | A - 8020 Graz
Mail/XMPP: sven.schwe...@tao.at | +43 (0)680 301 7167
http://software.tao.at



signature.asc
Description: OpenPGP digital signature

Re: No logs between Apr 25 - 27. What happened?

[lists]

  ‎My maillog doesn't rotate. Is this an option in postfix? Trawling the interwebs, I find maillog rotation handled outside postfix with custom scripts. From: Matthias AndreeSent: Monday, May 2, 2016 11:57 PMTo: tswmmeejsdad .; postfix-users@postfix.orgSubject: Re: No logs between Apr 25 - 27. What happened?Am 3. Mai 2016 06:15:55 MESZ, schrieb "tswmmeejsdad ." :
Hi All,Anyone know what I should check for to determine why logging to /var/log/mail stopped suddenly between Apr 25-27? I can see mail logs before and after those dates but nothing was logged between those dates. Mail was working fine else we would have had customers call up during those three days.Thanks.Andy
Check for:
- Syslog crashes
- Botched log rotation especially with compression vs. Signals (logrotate, newsyslog)
- Systemd/journal* malfunction on modern Linux 
- File system issues (skipped fsck after a crash) 
- Memory and other hw issues

Re: Adjusting custom transport for comcast.net's throttle

[Larry Stone]

> On May 2, 2016, at 10:40 PM, Noel Jones  wrote:
> 
> On 5/2/2016 8:42 PM, Steven Peterson wrote:
>> Thank you!  This was very helpful. 
>> 
>> By setting minimal_backoff_time to 300s globally, postfix now
>> attempts to send deferred messages to comcast.net
>>  every 10 minutes.  This is an improvement, but
>> it is not obvious why it sends every 10 minutes (600s) and not every
>> 5 minutes (300 seconds).  Is there another setting that is
>> preventing it from repeating every 300 seconds as the
>> minimal_backoff_time setting indicates?
>> 
>> Best, Steve
>> 
> 
> 
> First, note the minimal backoff is a guaranteed minimum, not a timer
> after which an attempt will be tried immediately.  Other mail in the
> queue or system load may delay the next retry.  A badly clogged mail
> queue may take hours until it gets around to a retry.
> 
> The queue delay settings are documented here:
> http://www.postfix.org/TUNING_README.html#hammer

Also in play is the value of queue_run_delay which is "The time between 
deferred queue scans by the queue manager”. The default is 300s so with 
minimal_backoff_time also 300s, when a send attempt ends and then 300s 
(minimal_backoff_time) elapses, the queue run has just occurred and so it waits 
another almost 300s until the next queue run. If you want it to try every 300s, 
set minimal_backoff_time to less than queue_run_delay so that the next queue 
run occurs soon after the backoff_time expires. Note also that the time between 
runs increases until it reaches maximal_backoff_time. Read the documentation 
Noel referenced above.

-- 
Larry Stone
lston...@stonejongleux.com