Re: Bounce mails manually

[azurit]

Citát "@lbutlr" :


On 15 Jan 2020, at 15:12, Noel Jones  wrote:
We've had problems with users mistyping domain names, such as  
hotmal.com or aoil.com. And they ignore the delay warning message  
because they still don't notice their typo.


Then they get the bounce when the max queue expires.

The messages in the queue are not hurting anything and unless there  
are millions and millions of them, they are not worth manually  
handling (nor adding custom transport maps to “fix” user’s tyops).



I don't agree with this. Yes, technically it isn't a problem but we  
(and for sure not alone) are using message queue size as a sign of a  
problem - if there are much more messages then usual, our monitoring  
software is notifying us. In most cases it is a sign of hacked account  
which is spamming - in about 50% of such cases, spammers are sending  
spam very slowly, so you cannot simply note it, that's why we monitor  
it. And that's why it is a problem when there are lots of messages  
which you cannot get rid of by any means.

Re: Max connection error message

[Esteban L]

Thank you Noel, just need a nudge in the right direction =)

On 15.01.20 21:18, Noel Jones wrote:
> On 1/15/2020 2:08 PM, Esteban L wrote:
>> Hello,
>>
>> I suspect this is equal parts a problem from Thunderbird, as it is
>> anything else. But, I am getting an error message:
>>
>>
>> Unable to connect to your IMAP server. You may have exceeded the maximum
>> number of connections to this server. If so, use the Advanced IMAP
>> server Settings dialogue to reduce the number of cached connections.
>>
>>
>> Is there a way to "fix"/massage this from within Postfix? I have a few
>> different users have the exact same problem, and would rather not have
>> to go one-by-one to each client and tweak something client side.
>>
>> I just can't access the mail server, send mail, save drafts, or
>> anything.
>>
>> If I translocate via vpn, then it works.
>>
>> Thanks in advance.
>>
>>
>
> Postfix does not provide IMAP service.  You need to increase the
> connections allowed in your IMAP server - dovecot or whatever.
>
>
>
>   -- Noel Jones

-- 
https://www.little-beak.com
"Doing what we can."

Re: Bounce mails manually

[Viktor Dukhovni]

On Wed, Jan 15, 2020 at 07:16:30PM -0500, Michael Orlitzky wrote:

> I'd like to bounce these immediately as a courtesy to the sender.
> Blacklisting typo domains is a (technically incorrect) losing battle,
> and if the message is to a distribution list, then it's useful for the
> sender to know that the recipient is dead.

On the other hand, likely or existing typo-squatter domains, especially
if they (almost) match your own domain, or the domain of a client or
business partner, can be vehicles for costly data leaks.  A few
incorrect bounces may be quite acceptable collateral risk of preventing
known potential harm.

> Yes, they'd get the bounce anyway when the message expires. But if I've
> already done the thinkative work to figure out that the message will
> bounce, it's a win at zero cost to bounce it immediately.

This is tricky for multi-recipient mail, where different deferred
recipients may have different error reasons.  So overriding the error
message is generally wrong, you'd go with the errors already saved for
each recipient.

Therefore, if this were to be made possible, the right mechanism would
be to to somehow expedite message expiration, with normal processing
on message expiration happening earlier than it would otherwise.

This could be done by adding a place-holder record to the queue file,
that could be later atomically (one byte write) updated to indicate
that the message is administratively expired.  Such messages would
expire after the next delivery attempt and would not be deferred
again.

-- 
Viktor.

Re: Bounce mails manually

[Michael Orlitzky]

On 1/15/20 5:12 PM, Noel Jones wrote:
> 
> We've had problems with users mistyping domain names, such as hotmal.com
> or aoil.com. And they ignore the delay warning message because they
> still don't notice their typo. 

I can +1 this request, even if it's something I morally shouldn't need.

Sometimes while checking the queue for some other reason, I'll notice a
message that I'm sure won't be deliverable: typo domain, mailbox over
quota, moribund provider, etc.

I'd like to bounce these immediately as a courtesy to the sender.
Blacklisting typo domains is a (technically incorrect) losing battle,
and if the message is to a distribution list, then it's useful for the
sender to know that the recipient is dead.

Yes, they'd get the bounce anyway when the message expires. But if I've
already done the thinkative work to figure out that the message will
bounce, it's a win at zero cost to bounce it immediately.

Re: Bounce mails manually

[@lbutlr]

On 15 Jan 2020, at 16:11, @lbutlr  wrote:
> There is only so much diaper-changing you can do for your users.

Sorry, one other thing I wanted to add.

You have no control over mail DELIVERY to any domain that is not under your 
control. Even if everything in the headers is perfectly correct and the 
recipient exists at the domain and the messages is sent to the right server and 
accepted, whether the message is DELIVERED is entirely out of your control.

As one famous example, at one point Verizon device that they could reduce their 
spam load by discarding all emails that originated outside the US. They did not 
reject the emails, they did not notify other the sender nor the recipient that 
the messages were not delivered, they simply discarded them.

There was absolutely nothing that any mail admin could do about this.

Similarly, my wife’s employer used to very often discard messages sent with 
attachments, including at times internal mail from department heads to 
employees. One year, no one got their W2’s (their ’solution’ was to send a link 
to the W2 pdf in the form http://compaydomain/SSN/2011-W2.pdf). Again, no 
bounce, reject, or notice to either sender or recipient. Which messages? Who 
knows? Do they still do this? No idea, my wife stopped having anyone send mail 
to her work account and now only gets internal mail (and lots and lots of spam, 
of course, since their IT department, as should be obvious from this story, is 
entirely incompetent at handling mail).

Something about this should be in your aforementioned FAQ as well.

Just because the Postal service delivers a letter to an address doesn’t mean 
the people there do not put the mail directly into the shredder.



-- 
Si Hoc Legere Scis Nimium Eruditionis Habes

Re: Bounce mails manually

[@lbutlr]

On 15 Jan 2020, at 15:12, Noel Jones  wrote:
> We've had problems with users mistyping domain names, such as hotmal.com or 
> aoil.com. And they ignore the delay warning message because they still don't 
> notice their typo.

Then they get the bounce when the max queue expires.

The messages in the queue are not hurting anything and unless there are 
millions and millions of them, they are not worth manually handling (nor adding 
custom transport maps to “fix” user’s tyops).

If user's complain about message to invalid recipients not getting delivered 
then have an FAQ that clearly says that it is impossible to deliver mail to an 
invalid recipient, that they get a warning message, and that they get a bounce. 
If they ignore the warning message, they likely ignore the bounce as well.

Also, creating a transports map that says that the VALID hotmal.com domain is 
invalid is a terrible idea that will blow up when hotmal.com becomes a huge 
freemail system next week.

There is only so much diaper-changing you can do for your users.


-- 
"Are you pondering what I'm pondering?"
"Oh, I think so, Brain! But doing a clog dance in actual clogs will
give me awful blisters.”

Re: Bounce mails manually

[Noel Jones]

On 1/15/2020 3:42 PM, Bill Cole wrote:

On 15 Jan 2020, at 14:55, Emanuel wrote:

my question arose because of a user on my server who sent to many 
recipients without MX


Perhaps you just need to add reject_unknown_recipient_domain to 
smtpd_recipient_restrictions?





We've had problems with users mistyping domain names, such as 
hotmal.com or aoil.com. And they ignore the delay warning message 
because they still don't notice their typo.


As far as DNS is concerned these are real domains with A records, so 
they don't fail reject_unknown_recipient_domain. Some of them 
web-redirect to the expected page, others are web squatters.


But they don't run a mail service, so connections to port 25 just 
time out, and the mail sits in the queue until $maximal_queue_lifetime.


I've kinda-solved this problem by adding error: transport map 
entries for the more common typos my users land on.  I expect others 
will have a different list...




hotmal.comerror:5.1.2 hotmal.com is not valid.  Maybe try 
hotmail.com instead.
hotmail.org   error:5.1.2 hotmail.org is not valid.  Maybe try 
hotmail.com instead.

hotmial.com   error:5.1.2 hotmail.com not hotmial.com
hotmai.comerror:5.1.2 hotmail.com not hotmai.com
hotamil.com   error:5.1.2 hotmail.com not hotamil.com
hotmaill.com   error:5.1.2 hotmail.com not hotmaill.com
wanado.fr error:5.1.2 wanadoo.fr not wanado.fr
htomail.com   error:5.1.2 hotmail.com not htomail.com
hotemail.com  error:5.1.2 hotmail.com not hotemail.com
verizion.net  error:5.1.2 "verizion.net" is not valid - try verizon.net
msns.com  error:5.1.2 "msns.com" is not valid - try msn.com
aoil.com  error:5.1.2 try "aol.com" instead
gmial.com error:5.1.2 try "gmail.com" instead
aol.com.com error:5.1.2 try "aol.com" instead
cenurytel.net   error:5.1.2 did you mean "centurytel.net"?
comcaste.neterror:5.1.2 try "comcast.net" instead
comcat.net   error:5.1.2 try  "comcast.net" instead
comcost.com   error:5.1.2 try  "comcast.net" instead
comcst.net   error:5.1.2 try  "comcast.net" instead
c0mcast.net error:5.1.2 try "comcast.net" instead
cdomcast.neterror:5.1.2 try "comcast.net" instead
cherter.net error:5.1.2 try "charter.net" instead
at.net error:5.1.2 try "att.net" instead



  -- Noel Jones

Re: Bounce mails manually

[Viktor Dukhovni]

On Wed, Jan 15, 2020 at 09:32:43PM +0100, azu...@pobox.sk wrote:

> >> > Why? Someone was drunk and sent a bad email? Is "postsuper -d"
> >> > not sufficient?
> >> >
> >> >  Wietse
> >>
> >> Use case: Users are sending undeliverable e-mails which are filling up
> >> mail queue and you must wait few days until they are bounced. You
> >> cannot simply delete them because, if you do, sender won't know it's
> >> undeliverable and will send something to that address again in the
> >> future.

When you say "filling up mail queue" is that actually a problem, or just
something you could simply ignore with no ill-effect?  The mail will
bounce eventually after (by default) ~5 days.

> > Why not set a smaller maximal_queue_lifetime?

As Wietse suggests, you can typically set the queue lifetime a bit
shorter (perhaps 2 days, but generally not much shorter, allowing
remote sites to fix problems they did not notice immediately).
With 5 days, you can wait out an outage that lasts across a long
holiday weekend.  With 2 days, an outage that does not get noticed
until the next morning and takes a day to fix.

> Because there can be legitimate situations where it is good to keep  
> e-mails longer in the queue (full mailbox, temporary outage of  
> recipient server [which can take days] etc.).

Which is why on outbound Postfix instances I tend to set:

delay_warning_time = 2h,

giving my own senders generally same day notice of email that'll likely
never make it, but retries continue for ~2-5 days.  In commercial
deployments serving more than a handful of users, I always separate
inbound and outbound processing into separate Postfix instances.
The inbound queue has the default "delay_warning_time = 0h", which
does not leak internal hiccups to outsiders.

-- 
Viktor.

Re: Bounce mails manually

[Bill Cole]

On 15 Jan 2020, at 14:55, Emanuel wrote:

my question arose because of a user on my server who sent to many 
recipients without MX


Perhaps you just need to add reject_unknown_recipient_domain to 
smtpd_recipient_restrictions?


--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not For Hire (currently)

Re: Bounce mails manually

[Wietse Venema]

Jaroslaw Rafa:
> Dnia 15.01.2020 o godz. 20:47:45 azu...@pobox.sk pisze:
> > 
> > Use case: Users are sending undeliverable e-mails which are filling
> > up mail queue and you must wait few days until they are bounced. You
> > cannot simply delete them because, if you do, sender won't know it's
> > undeliverable and will send something to that address again in the
> > future.
> 
> Can't you just write a simple script that extracts sender and recipient from
> the message in queue, deletes the message and sends an email to the sender
> informing that the recipient address is undeliverable?

If the sender needs to be informed (i.e it's not malware or spam)
then it makes sense to return the message as undeliverable so that
here is no loss of information.

Wietse

Re: Bounce mails manually

[Jaroslaw Rafa]

Dnia 15.01.2020 o godz. 20:47:45 azu...@pobox.sk pisze:
> 
> Use case: Users are sending undeliverable e-mails which are filling
> up mail queue and you must wait few days until they are bounced. You
> cannot simply delete them because, if you do, sender won't know it's
> undeliverable and will send something to that address again in the
> future.

Can't you just write a simple script that extracts sender and recipient from
the message in queue, deletes the message and sends an email to the sender
informing that the recipient address is undeliverable?
-- 
Regards,
   Jaroslaw Rafa
   r...@rafa.eu.org
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."

Re: Bounce mails manually

[azurit]

Citát Wietse Venema :


azu...@pobox.sk:


Cit?t Wietse Venema :

> azu...@pobox.sk:
>>
>> Cit?t Wietse Venema :
>>
>> > Emanuel:
>> >> Hello,
>> >>
>> >> It's possible bouncing email manually with the ID in the queue?
>> >>
>> >> In the documentati?n from de the command postqueue or postsuper i not
>> >> find any information.
>> >
>> > That's because bounce by ID is not supported.
>> >
>> > You can bounce all mail for a specific recipient or a specific domain
>> > with a transport map.
>> >
>> > /etc/postfix/main.cf
>> > transport_maps = hash:/etc/postfix/transport
>> >
>> > /etc/postfix/transport
>> > example.com error:text why mail is bounced
>> > u...@other.example.com  error:text why mail is bounced
>> >
>> > Instead of hash: you can use any Postfix darabase type.
>> >
>> > This also prevents the Postfix SMTP server from accepting new email
>> > for that recipient or domain.
>> >
>> > A postsuper 'bounce' option would require
>> > - Must be invoked by root.
>> > - Drop privileges down to the postfix user.
>> > - Lock the queue file for exclusive access.
>> > - Either set a new flag in the queue file that the message must
>> be bounced,
>> > - Or for each recipient in the queue file send 'why mail is bounced'
>> >   to the bounce daemon.
>> >
>> >   Wietse
>>
>>
>>
>> But it would be REALLY usefull feature, i was searching for such thing
>> some time ago too.
>
> Why? Someone was drunk and sent a bad email? Is "postsuper -d" not
> sufficient?
>
>Wietse




Use case: Users are sending undeliverable e-mails which are filling up
mail queue and you must wait few days until they are bounced. You
cannot simply delete them because, if you do, sender won't know it's
undeliverable and will send something to that address again in the
future.


Why not set a smaller maximal_queue_lifetime?

Wietse




Because there can be legitimate situations where it is good to keep  
e-mails longer in the queue (full mailbox, temporary outage of  
recipient server [which can take days] etc.).

Re: Max connection error message

[Noel Jones]

On 1/15/2020 2:08 PM, Esteban L wrote:

Hello,

I suspect this is equal parts a problem from Thunderbird, as it is
anything else. But, I am getting an error message:


Unable to connect to your IMAP server. You may have exceeded the maximum
number of connections to this server. If so, use the Advanced IMAP
server Settings dialogue to reduce the number of cached connections.


Is there a way to "fix"/massage this from within Postfix? I have a few
different users have the exact same problem, and would rather not have
to go one-by-one to each client and tweak something client side.

I just can't access the mail server, send mail, save drafts, or anything.

If I translocate via vpn, then it works.

Thanks in advance.




Postfix does not provide IMAP service.  You need to increase the 
connections allowed in your IMAP server - dovecot or whatever.




  -- Noel Jones

Re: Max connection error message

[Wietse Venema]

Esteban L:
> Hello,
> 
> I suspect this is equal parts a problem from Thunderbird, as it is
> anything else. But, I am getting an error message:
> 
> 
> Unable to connect to your IMAP server. You may have exceeded the maximum
> number of connections to this server. If so, use the Advanced IMAP
> server Settings dialogue to reduce the number of cached connections.

This is not a POSTFIX error message.
 
Wietse

Max connection error message

[Esteban L]

Hello,

I suspect this is equal parts a problem from Thunderbird, as it is
anything else. But, I am getting an error message:


Unable to connect to your IMAP server. You may have exceeded the maximum
number of connections to this server. If so, use the Advanced IMAP
server Settings dialogue to reduce the number of cached connections.


Is there a way to "fix"/massage this from within Postfix? I have a few
different users have the exact same problem, and would rather not have
to go one-by-one to each client and tweak something client side.

I just can't access the mail server, send mail, save drafts, or anything.

If I translocate via vpn, then it works.

Thanks in advance.


-- 
https://www.little-beak.com
"Doing what we can."

Re: Bounce mails manually

[Wietse Venema]

azu...@pobox.sk:
> 
> Cit?t Wietse Venema :
> 
> > azu...@pobox.sk:
> >>
> >> Cit?t Wietse Venema :
> >>
> >> > Emanuel:
> >> >> Hello,
> >> >>
> >> >> It's possible bouncing email manually with the ID in the queue?
> >> >>
> >> >> In the documentati?n from de the command postqueue or postsuper i not
> >> >> find any information.
> >> >
> >> > That's because bounce by ID is not supported.
> >> >
> >> > You can bounce all mail for a specific recipient or a specific domain
> >> > with a transport map.
> >> >
> >> > /etc/postfix/main.cf
> >> > transport_maps = hash:/etc/postfix/transport
> >> >
> >> > /etc/postfix/transport
> >> > example.com error:text why mail is bounced
> >> > u...@other.example.com  error:text why mail is bounced
> >> >
> >> > Instead of hash: you can use any Postfix darabase type.
> >> >
> >> > This also prevents the Postfix SMTP server from accepting new email
> >> > for that recipient or domain.
> >> >
> >> > A postsuper 'bounce' option would require
> >> > - Must be invoked by root.
> >> > - Drop privileges down to the postfix user.
> >> > - Lock the queue file for exclusive access.
> >> > - Either set a new flag in the queue file that the message must  
> >> be bounced,
> >> > - Or for each recipient in the queue file send 'why mail is bounced'
> >> >   to the bounce daemon.
> >> >
> >> >  Wietse
> >>
> >>
> >>
> >> But it would be REALLY usefull feature, i was searching for such thing
> >> some time ago too.
> >
> > Why? Someone was drunk and sent a bad email? Is "postsuper -d" not
> > sufficient?
> >
> > Wietse
> 
> 
> 
> 
> Use case: Users are sending undeliverable e-mails which are filling up  
> mail queue and you must wait few days until they are bounced. You  
> cannot simply delete them because, if you do, sender won't know it's  
> undeliverable and will send something to that address again in the  
> future.

Why not set a smaller maximal_queue_lifetime?

Wietse

Re: Bounce mails manually

[Emanuel]

Hello everyone,

my question arose because of a user on my server who sent to many 
recipients without MX, then the mail was queued until the expiration time:


bounce_queue_lifetime = 5h

the idea was to reject emails manually with the error message that returned:

Example:

│Message: 06CB318005A26 │
│From..: "Rene Alvarado"  │
│To:  │
│Subj..: SALDO PENDIENTE │
│Status: connect to impresosms.com[45.204.127.107]:25: No route to host

Regards,

El 15/1/20 a las 16:47, azu...@pobox.sk escribió:


Citát Wietse Venema :


azu...@pobox.sk:


Cit?t Wietse Venema :

> Emanuel:
>> Hello,
>>
>> It's possible bouncing email manually with the ID in the queue?
>>
>> In the documentati?n from de the command postqueue or postsuper i 
not

>> find any information.
>
> That's because bounce by ID is not supported.
>
> You can bounce all mail for a specific recipient or a specific domain
> with a transport map.
>
> /etc/postfix/main.cf
> transport_maps = hash:/etc/postfix/transport
>
> /etc/postfix/transport
> example.com error:text why mail is bounced
> u...@other.example.com  error:text why mail is bounced
>
> Instead of hash: you can use any Postfix darabase type.
>
> This also prevents the Postfix SMTP server from accepting new email
> for that recipient or domain.
>
> A postsuper 'bounce' option would require
> - Must be invoked by root.
> - Drop privileges down to the postfix user.
> - Lock the queue file for exclusive access.
> - Either set a new flag in the queue file that the message must be 
bounced,

> - Or for each recipient in the queue file send 'why mail is bounced'
>   to the bounce daemon.
>
> Wietse



But it would be REALLY usefull feature, i was searching for such thing
some time ago too.


Why? Someone was drunk and sent a bad email? Is "postsuper -d" not
sufficient?

Wietse





Use case: Users are sending undeliverable e-mails which are filling up 
mail queue and you must wait few days until they are bounced. You 
cannot simply delete them because, if you do, sender won't know it's 
undeliverable and will send something to that address again in the 
future.




--

Re: Bounce mails manually

[azurit]

Citát Wietse Venema :


azu...@pobox.sk:


Cit?t Wietse Venema :

> Emanuel:
>> Hello,
>>
>> It's possible bouncing email manually with the ID in the queue?
>>
>> In the documentati?n from de the command postqueue or postsuper i not
>> find any information.
>
> That's because bounce by ID is not supported.
>
> You can bounce all mail for a specific recipient or a specific domain
> with a transport map.
>
> /etc/postfix/main.cf
> transport_maps = hash:/etc/postfix/transport
>
> /etc/postfix/transport
> example.com error:text why mail is bounced
> u...@other.example.com  error:text why mail is bounced
>
> Instead of hash: you can use any Postfix darabase type.
>
> This also prevents the Postfix SMTP server from accepting new email
> for that recipient or domain.
>
> A postsuper 'bounce' option would require
> - Must be invoked by root.
> - Drop privileges down to the postfix user.
> - Lock the queue file for exclusive access.
> - Either set a new flag in the queue file that the message must  
be bounced,

> - Or for each recipient in the queue file send 'why mail is bounced'
>   to the bounce daemon.
>
>Wietse



But it would be REALLY usefull feature, i was searching for such thing
some time ago too.


Why? Someone was drunk and sent a bad email? Is "postsuper -d" not
sufficient?

Wietse





Use case: Users are sending undeliverable e-mails which are filling up  
mail queue and you must wait few days until they are bounced. You  
cannot simply delete them because, if you do, sender won't know it's  
undeliverable and will send something to that address again in the  
future.

Re: Bounce mails manually

[Wietse Venema]

azu...@pobox.sk:
> 
> Cit?t Wietse Venema :
> 
> > Emanuel:
> >> Hello,
> >>
> >> It's possible bouncing email manually with the ID in the queue?
> >>
> >> In the documentati?n from de the command postqueue or postsuper i not
> >> find any information.
> >
> > That's because bounce by ID is not supported.
> >
> > You can bounce all mail for a specific recipient or a specific domain
> > with a transport map.
> >
> > /etc/postfix/main.cf
> > transport_maps = hash:/etc/postfix/transport
> >
> > /etc/postfix/transport
> > example.com error:text why mail is bounced
> > u...@other.example.com  error:text why mail is bounced
> >
> > Instead of hash: you can use any Postfix darabase type.
> >
> > This also prevents the Postfix SMTP server from accepting new email
> > for that recipient or domain.
> >
> > A postsuper 'bounce' option would require
> > - Must be invoked by root.
> > - Drop privileges down to the postfix user.
> > - Lock the queue file for exclusive access.
> > - Either set a new flag in the queue file that the message must be bounced,
> > - Or for each recipient in the queue file send 'why mail is bounced'
> >   to the bounce daemon.
> >
> > Wietse
> 
> 
> 
> But it would be REALLY usefull feature, i was searching for such thing  
> some time ago too.

Why? Someone was drunk and sent a bad email? Is "postsuper -d" not
sufficient?

Wietse

Re: Bounce mails manually

[azurit]

Citát Wietse Venema :


Emanuel:

Hello,

It's possible bouncing email manually with the ID in the queue?

In the documentati?n from de the command postqueue or postsuper i not
find any information.


That's because bounce by ID is not supported.

You can bounce all mail for a specific recipient or a specific domain
with a transport map.

/etc/postfix/main.cf
transport_maps = hash:/etc/postfix/transport

/etc/postfix/transport
example.com error:text why mail is bounced
u...@other.example.com  error:text why mail is bounced

Instead of hash: you can use any Postfix darabase type.

This also prevents the Postfix SMTP server from accepting new email
for that recipient or domain.

A postsuper 'bounce' option would require
- Must be invoked by root.
- Drop privileges down to the postfix user.
- Lock the queue file for exclusive access.
- Either set a new flag in the queue file that the message must be bounced,
- Or for each recipient in the queue file send 'why mail is bounced'
  to the bounce daemon.

Wietse




But it would be REALLY usefull feature, i was searching for such thing  
some time ago too.


azur

Re: Bounce mails manually

[Wietse Venema]

Emanuel:
> Hello,
> 
> It's possible bouncing email manually with the ID in the queue?
> 
> In the documentati?n from de the command postqueue or postsuper i not 
> find any information.

That's because bounce by ID is not supported.

You can bounce all mail for a specific recipient or a specific domain
with a transport map.

/etc/postfix/main.cf
transport_maps = hash:/etc/postfix/transport

/etc/postfix/transport
example.com error:text why mail is bounced
u...@other.example.com  error:text why mail is bounced

Instead of hash: you can use any Postfix darabase type.

This also prevents the Postfix SMTP server from accepting new email
for that recipient or domain.

A postsuper 'bounce' option would require
- Must be invoked by root.
- Drop privileges down to the postfix user.
- Lock the queue file for exclusive access.
- Either set a new flag in the queue file that the message must be bounced,
- Or for each recipient in the queue file send 'why mail is bounced'
  to the bounce daemon.

Wietse

Bounce mails manually

[Emanuel]

Hello,

It's possible bouncing email manually with the ID in the queue?

In the documentatión from de the command postqueue or postsuper i not 
find any information.


Regards,

--

Re: Disable function "said: 550 Blocked by SPF () (in reply to MAIL FROM command))"

[Emanuel]

Thanks for the help.!!!

Regards,

El 14/1/20 a las 09:58, Dominic Raferd escribió:



On Tue, 14 Jan 2020 at 12:53, Scott Kitterman > wrote:


On Tuesday, January 14, 2020 7:39:05 AM EST Emanuel wrote:
> Hello everyone.!
>
> I see this error in the postfix logs:
>
> said: 550 Blocked by SPF () (in reply to MAIL FROM command))
>
> Jan 14 09:31:46 antartida postfix/smtpd[16086]: 9248680010:
> client=a48-146.smtp-out.amazonses.com
[54.240.48.146]
> Jan 14 09:31:46 antartida postfix/cleanup[16162]: 9248680010:
>
message-id=<0100016fa4095ae5-d7ad3acb-ae83-4ec5-98b7-2caf1aa89dda-00@ema
> il.amazonses.com > Jan 14 09:31:47
antartida postfix/qmgr[16065]: 9248680010:
>
from=<0100016fa4095ae5-d7ad3acb-ae83-4ec5-98b7-2caf1aa89dda-00@amazonses
> .com>, size=18774, nrcpt=1 (queue active)
> Jan 14 09:31:47 antartida postfix/smtp[16067]: 9248680010:
> to=mailto:i...@aylendepartamentos.com.ar>>,
> relay=mail.aylendepartamentos.com.ar
[200.58.120.110]:25, delay=1.8,
> delays=1.6/0/0.17/0, dsn=4.0.0, status=SOFTBOUNCE (host
> mail.aylendepartamentos.com.ar
[200.58.120.110] said: 550
Blocked by SPF
> () (in reply to MAIL FROM command))
>
> Postifix does not use any spf policy, the configuration is here:
>
> https://pastebin.com/kK6yCnFM
>
> any ideas? I'm losing emails because of this
>
> Regards,

The error message comes from the remote server.  Based on a quick
Google
Search, it's hmailserver [1], nothing to do with Postfix. Since
it's SPF
specific, the spf-help mailing list [2] would be a good place to
ask for help.

Scott K

[1] https://www.hmailserver.com/
[2] https://spf.topicbox.com/groups/spf-help/subscription


As Scott has written, the blockage is being done by the onward server 
(mail.aylendepartamentos.com.ar 
) not by your postfix (clue: 
the message is logged by 'smtp' not by 'smtpd'). They seem to be 
applying the SPF rule from amazonses.com  which 
includes '-all'. It is an unwise policy on their part as SPF is broken 
by relaying such as you are doing. If you have to relay in this way to 
this server, and you can't persuade them to change their policy, 
consider encapsulating such mails (i.e. sending on as attachments).

--
envialosimple.com   
Emanuel Gonzalez
IT / Departamento Emails
emanuel.gonza...@donweb.com 
www.envialosimple.com 
by donweb 

Nota de confidencialidad: Este mensaje y archivos adjuntos al mismo son 
confidenciales, de uso exclusivo para el destinatario del mismo. La 
divulgación y/o uso del mismo sin autorización por parte de DonWeb.com 
queda prohibida.
DonWeb.com no se hace responsable del mensaje por la falsificación y/o 
alteración del mismo.
De no ser Ud el destinatario del mismo y lo ha recibido por error, por 
favor, notifique al remitente y elimínelo de su sistema.
Confidentiality Note: This message and any attachments (the message) are 
confidential and intended solely for the addressees. Any unauthorised 
use or dissemination is prohibited by DonWeb.com.

DonWeb.com shall not be liable  for the message if altered or falsified.
If you are not the intended addressee of this message, please cancel it 
immediately and inform the sender
Nota de Confidencialidade: Esta mensagem e seus eventuais anexos podem 
conter dados confidenciais ou privilegiados.
Se você os recebeu por engano ou não é um dos destinatários aos quais 
ela foi endereçada, por favor destrua-a e a todos os seus eventuais 
anexos ou copias realizadas, imediatamente.
É proibida a retenção, distribuição, divulgação ou utilização de 
quaisquer informações aqui contidas.
Por favor, informenos sobre o recebimento indevido desta mensagem, 
retornando-a para o autor.

Re: PATCH: milter API function smfi_setsymlist

[David Bürgin]

On 15/01/2020 16:37, Wietse Venema wrote:
> As implemented in this patch: move the on-the-fly connect before
> the macroi evaluation. Should work for Postfix 2.5 and later.

Thank you very much.

I would try it out, unfortunately I have never set up Postfix from the
raw materials myself (I’m using the Debian/Ubuntu package). So I don’t
know when I will get around to doing so. Thanks again.

Re: Postfix HELO checks

[Simon B]

On Wed, 15 Jan 2020 at 18:00, Dominic Raferd  wrote:
>
>
> On Wed, 15 Jan 2020 at 16:50, Simon B  wrote:
>>
>> On Wed, 15 Jan 2020 at 17:43, Jaroslaw Rafa  wrote:
>> >
>> > Dnia 15.01.2020 o godz. 17:26:48 Simon B pisze:
>> > >
>> > > Amavis listens on 10024, and postfix listens on 10025
>> > >
>> > > That means mail comes in on 587, it goes to amavis on 10024 and comes
>> > > back on 10025 before going out.
>> > [...]
>> > > and mail is flowing.  I am not happy since the solution to the
>> > > original problem has been to make smtpd_helo_restrictions=permit and
>> > > even though it's internal we operate a zero-trust policy, and "permit"
>> > > is not that.
>> >
>> > Does Amavis actually connect to 127.0.0.1 when injecting mail back to
>> > Postfix? If yes, then maybe you don't have 127.0.0.1 in $mynetworks
>> >
>> > It can also be that Amavis doesn't connect to 127.0.0.1, but to some other
>> > IP on your server - then you need to put that IP in $mynetworks too, or
>> > reconfigure Amavis so that it connects to 127.0.0.1
>>
>> I don't know where else it could connect...  In master.cf it is defined
>>
>> 119 #The amavis reciever
>> 120 127.0.0.1:10025 inet n - - - - smtpd
>>
>> > If it works with "permit", it should also work with "permit_mynetworks",
>> > provided that the value of $mynetworks includes the actual IP Amavis is
>> > connecting to.
>>
>> it should, but it isn't - hence the reason I have asked here for help.
>>
>> # postconf -n | grep -n mynetworks
>> 36:mynetworks = 127.0.0.0/8, [::1]/128
>> 37:mynetworks_style = host
>
>
> Try removing 'mynetworks' from definitions since it overwrites 
> 'mynetworks_style=host' which should already restrict the definition of 
> mynetworks to the local machine (and might do so in a more correct way?)
> Try adding 'reject' after 'permit_mynetworks' at the end of one of the 
> restriction lists (for smtpd-from-amavis) e.g. smtpd_client_restrictions - 
> this gives you the full protection

Thanks.  That works and meets our objectives.

Appreciate the fantastic support.

Simon

Re: make smtpd listen on IPv6 as well

[Simon B]

On Wed, 15 Jan 2020 at 18:03, Wietse Venema  wrote:
>
> Simon B:
> > Hi
> >
> > Currently the smtpd for receiving mails from amavis is set up like:
> >
> > 119 #The amavis reciever
> > 120 127.0.0.1:10025 inet n - - - - smtpd
> >
> > Consequently it listens only IPv4
> >
> > ~# netstat -tulpn | grep 10025
> > tcp0  0 127.0.0.1:10025 0.0.0.0:*
> > LISTEN  4849/master
> >
> > Amavis is listening on both IPv4 and IPv6
> >
> > # netstat -tulpn | grep 10024
> > tcp0  0 127.0.0.1:10024 0.0.0.0:*
> > LISTEN  4135/amavisd-new (m
> > tcp6   0  0 ::1:10024   :::*
> > LISTEN  4135/amavisd-new (m
> >
> > Do I need to duplicate the entry in master.cf or is there some more
> > elegant way to do it?
>
> Specify 'localhost' instead of an IP address, and add 'localhost' entries
> to /etc/hosts to avoid problems at boot time.

Thanks Wietse.  I went with this option.

> Alternatively specify no host, just 10025, in master.cf, and specify
> inet_interfaces=loopback in main.cf.

This option closes the submission port on the external interface.

(for anyone else reading the archives, postconf.5 says the accepted value is:

inet_interfaces = loopback-only (Postfix version 2.2 and later))

Regards

Simon

Re: make smtpd listen on IPv6 as well

[Dominic Raferd]

On Wed, 15 Jan 2020 at 17:03, Wietse Venema  wrote:

> Simon B:
> > Hi
> >
> > Currently the smtpd for receiving mails from amavis is set up like:
> >
> > 119 #The amavis reciever
> > 120 127.0.0.1:10025 inet n - - - - smtpd
> >
> > Consequently it listens only IPv4
> >
> > ~# netstat -tulpn | grep 10025
> > tcp0  0 127.0.0.1:10025 0.0.0.0:*
> > LISTEN  4849/master
> >
> > Amavis is listening on both IPv4 and IPv6
> >
> > # netstat -tulpn | grep 10024
> > tcp0  0 127.0.0.1:10024 0.0.0.0:*
> > LISTEN  4135/amavisd-new (m
> > tcp6   0  0 ::1:10024   :::*
> > LISTEN  4135/amavisd-new (m
> >
> > Do I need to duplicate the entry in master.cf or is there some more
> > elegant way to do it?
>
> Specify 'localhost' instead of an IP address, and add 'localhost' entries
> to /etc/hosts to avoid problems at boot time.
>
> Alternatively specify no host, just 10025, in master.cf, and specify
> inet_interfaces=loopback in main.cf.
>
> Wietse
>
> > Currently inet is defined in main.cf as
> >
> >  # postconf -n | grep -n inet
> > 25:inet_interfaces = all
>

Or add

$inet_socket_bind = '127.0.0.1';

to your amavis configuration, which should stop it listening on ipv6

Re: make smtpd listen on IPv6 as well

[Wietse Venema]

Simon B:
> Hi
> 
> Currently the smtpd for receiving mails from amavis is set up like:
> 
> 119 #The amavis reciever
> 120 127.0.0.1:10025 inet n - - - - smtpd
> 
> Consequently it listens only IPv4
> 
> ~# netstat -tulpn | grep 10025
> tcp0  0 127.0.0.1:10025 0.0.0.0:*
> LISTEN  4849/master
> 
> Amavis is listening on both IPv4 and IPv6
> 
> # netstat -tulpn | grep 10024
> tcp0  0 127.0.0.1:10024 0.0.0.0:*
> LISTEN  4135/amavisd-new (m
> tcp6   0  0 ::1:10024   :::*
> LISTEN  4135/amavisd-new (m
> 
> Do I need to duplicate the entry in master.cf or is there some more
> elegant way to do it?

Specify 'localhost' instead of an IP address, and add 'localhost' entries
to /etc/hosts to avoid problems at boot time.

Alternatively specify no host, just 10025, in master.cf, and specify
inet_interfaces=loopback in main.cf.

Wietse

> Currently inet is defined in main.cf as
> 
>  # postconf -n | grep -n inet
> 25:inet_interfaces = all
> 
> Thanks.
> 
> Simon
> 

Re: Postfix HELO checks

[Dominic Raferd]

On Wed, 15 Jan 2020 at 16:50, Simon B  wrote:

> On Wed, 15 Jan 2020 at 17:43, Jaroslaw Rafa  wrote:
> >
> > Dnia 15.01.2020 o godz. 17:26:48 Simon B pisze:
> > >
> > > Amavis listens on 10024, and postfix listens on 10025
> > >
> > > That means mail comes in on 587, it goes to amavis on 10024 and comes
> > > back on 10025 before going out.
> > [...]
> > > and mail is flowing.  I am not happy since the solution to the
> > > original problem has been to make smtpd_helo_restrictions=permit and
> > > even though it's internal we operate a zero-trust policy, and "permit"
> > > is not that.
> >
> > Does Amavis actually connect to 127.0.0.1 when injecting mail back to
> > Postfix? If yes, then maybe you don't have 127.0.0.1 in $mynetworks
> >
> > It can also be that Amavis doesn't connect to 127.0.0.1, but to some
> other
> > IP on your server - then you need to put that IP in $mynetworks too, or
> > reconfigure Amavis so that it connects to 127.0.0.1
>
> I don't know where else it could connect...  In master.cf it is defined
>
> 119 #The amavis reciever
> 120 127.0.0.1:10025 inet n - - - - smtpd
>
> > If it works with "permit", it should also work with "permit_mynetworks",
> > provided that the value of $mynetworks includes the actual IP Amavis is
> > connecting to.
>
> it should, but it isn't - hence the reason I have asked here for help.
>
> # postconf -n | grep -n mynetworks
> 36:mynetworks = 127.0.0.0/8, [::1]/128
> 37:mynetworks_style = host
>

Try removing 'mynetworks' from definitions since it overwrites
'mynetworks_style=host' which should already restrict the definition of
mynetworks to the local machine (and might do so in a more correct way?)
Try adding 'reject' after 'permit_mynetworks' at the end of one of the
restriction lists (for smtpd-from-amavis) e.g. smtpd_client_restrictions -
this gives you the full protection

Re: Postfix HELO checks

[Simon B]

On Wed, 15 Jan 2020 at 17:43, Jaroslaw Rafa  wrote:
>
> Dnia 15.01.2020 o godz. 17:26:48 Simon B pisze:
> >
> > Amavis listens on 10024, and postfix listens on 10025
> >
> > That means mail comes in on 587, it goes to amavis on 10024 and comes
> > back on 10025 before going out.
> [...]
> > and mail is flowing.  I am not happy since the solution to the
> > original problem has been to make smtpd_helo_restrictions=permit and
> > even though it's internal we operate a zero-trust policy, and "permit"
> > is not that.
>
> Does Amavis actually connect to 127.0.0.1 when injecting mail back to
> Postfix? If yes, then maybe you don't have 127.0.0.1 in $mynetworks
>
> It can also be that Amavis doesn't connect to 127.0.0.1, but to some other
> IP on your server - then you need to put that IP in $mynetworks too, or
> reconfigure Amavis so that it connects to 127.0.0.1

I don't know where else it could connect...  In master.cf it is defined

119 #The amavis reciever
120 127.0.0.1:10025 inet n - - - - smtpd

> If it works with "permit", it should also work with "permit_mynetworks",
> provided that the value of $mynetworks includes the actual IP Amavis is
> connecting to.

it should, but it isn't - hence the reason I have asked here for help.

# postconf -n | grep -n mynetworks
36:mynetworks = 127.0.0.0/8, [::1]/128
37:mynetworks_style = host

Regards

Simon

make smtpd listen on IPv6 as well

[Simon B]

Hi

Currently the smtpd for receiving mails from amavis is set up like:

119 #The amavis reciever
120 127.0.0.1:10025 inet n - - - - smtpd

Consequently it listens only IPv4

~# netstat -tulpn | grep 10025
tcp0  0 127.0.0.1:10025 0.0.0.0:*
LISTEN  4849/master

Amavis is listening on both IPv4 and IPv6

# netstat -tulpn | grep 10024
tcp0  0 127.0.0.1:10024 0.0.0.0:*
LISTEN  4135/amavisd-new (m
tcp6   0  0 ::1:10024   :::*
LISTEN  4135/amavisd-new (m

Do I need to duplicate the entry in master.cf or is there some more
elegant way to do it?

Currently inet is defined in main.cf as

 # postconf -n | grep -n inet
25:inet_interfaces = all

Thanks.

Simon

Re: Postfix HELO checks

[Jaroslaw Rafa]

Dnia 15.01.2020 o godz. 17:26:48 Simon B pisze:
> 
> Amavis listens on 10024, and postfix listens on 10025
> 
> That means mail comes in on 587, it goes to amavis on 10024 and comes
> back on 10025 before going out.
[...]
> and mail is flowing.  I am not happy since the solution to the
> original problem has been to make smtpd_helo_restrictions=permit and
> even though it's internal we operate a zero-trust policy, and "permit"
> is not that.

Does Amavis actually connect to 127.0.0.1 when injecting mail back to
Postfix? If yes, then maybe you don't have 127.0.0.1 in $mynetworks

It can also be that Amavis doesn't connect to 127.0.0.1, but to some other
IP on your server - then you need to put that IP in $mynetworks too, or
reconfigure Amavis so that it connects to 127.0.0.1

If it works with "permit", it should also work with "permit_mynetworks",
provided that the value of $mynetworks includes the actual IP Amavis is
connecting to.
-- 
Regards,
   Jaroslaw Rafa
   r...@rafa.eu.org
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."

Re: Need this rule: Everybody may receive from specific address / a few may receive from any address or domain

[rdquiterio]

Hi Bob;

You are right. The problem is that I cannot implement both conditions in my
antisspam proxy (ASSP). I can do the second condition but not both. So,
currently, the appliance is allowing any mail to and from our recipients.

Your suggestions will almost surely solve my problem. 

I just forgot to mention that I want those who are allowed to receive to be
also allowed to send to anybody. For that, I think will I need something
like:

   smtpd_sender_restrictions
…
check_sender_access hash:/etc/postfix/sender-access
   …
   any other prameters??

Thank you very much. You gave me a big help.
Rafael



--
Sent from: http://postfix.1071664.n5.nabble.com/Postfix-Users-f2.html

Re: Postfix HELO checks

[Simon B]

On Wed, 15 Jan 2020 at 15:57, Dominic Raferd  wrote:
>
>
>
> On Wed, 15 Jan 2020 at 13:36, Simon B  wrote:
>>
>> On Wed, 15 Jan 2020 at 13:40, Matus UHLAR - fantomas  
>> wrote:
>> >
>> > >> On Mon, Jan 13, 2020 at 06:25:27PM +0100, Simon B wrote:
>> > >> > > > >> >Since upgrading to 2.11 yesterday (yes, I am on a path to 
>> > >> > > > >> >move up
>> > >> > > > >> >through debian versions), all mail coming in on
>> > >> > > > >> >postfix/submission/smtpd is being rejected by the domain 
>> > >> > > > >> >check in that
>> > >> > > > >> >file, even though the user is sasl authenticated.
>> >
>> > >On Mon, 13 Jan 2020 at 18:44, Viktor Dukhovni
>> > > wrote:
>> > >> Note, Postfix 2.11 (actually 2.10 IIRC) adds "smtpd_relay_restrictions",
>> > >> which you don't override in the submission service definition:
>> >
>> > On 15.01.20 13:19, Simon B wrote:
>> > >Cause and effect in one simple sentence - thanks Viktor!
>> >
>> > if you use debian, the default smtpd_relay_restrictions should contain:
>> >
>> > smtpd_relay_restrictions=permit_mynetworks permit_sasl_authenticated 
>> > defer_unauth_destination
>>
>> That results in this
>> Jan 15 13:32:53 mail postfix/smtpd[743]: NOQUEUE: reject: RCPT from
>> localhost[127.0.0.1]: 451 4.3.5 Server configuration error;

>> > >Despite the fact that I changed those receiver settings in master.cf to:
>> > >
>> > >118 #The amavis reciever
>> > >119 127.0.0.1:10025 inet n - - - - smtpd
>> > >120 -o content_filter=
>> > >121 -o local_recipient_maps=
>> > >122 -o relay_recipient_maps=
>> > >123 -o smtpd_restriction_classes=
>> > >124   -o 
>> > >smtpd_client_restrictions=permit_mynetworks,reject_plaintext_session
>> > >125   -o smtpd_helo_restrictions=permit_mynetworks
>> > >126 -o smtpd_sender_restrictions=
>> > >127 -o smtpd_recipient_restrictions=permit_mynetworks,reject
>> > >128 -o mynetworks=127.0.0.0/8
>> > >129 -o strict_rfc821_envelopes=yes
>> > >130 -o 
>> > >receive_override_options=no_unknown_recipient_checks,no_header_body_checks
>> > >131 -o smtp_bind_address=127.0.0.1
>> > >
>> > >At the moment nothing is going through amavis in either direction, so
>> > >that's a problem...
>> >
>> > are you sure amavis sends mail through port 10025?
>>
>> Hi Matus,
>>
>> Yes, very sure.
>>
>> if I turn on -v logging for that hop, I am concerned about these lines
>> in the log.
>>
>> Jan 15 13:09:01 mail postfix/smtpd[466]: < localhost[127.0.0.1]: EHLO
>> amavisd.localhost
>> Jan 15 13:09:01 mail postfix/smtpd[466]: match_list_match: localhost: no 
>> match
>> Jan 15 13:09:01 mail postfix/smtpd[466]: match_list_match: 127.0.0.1: no 
>> match
>> and
>> Jan 15 13:09:01 mail postfix/smtpd[466]: generic_checks: 
>> name=permit_mynetworks
>> Jan 15 13:09:01 mail postfix/smtpd[466]: permit_mynetworks: localhost 
>> 127.0.0.1
>> Jan 15 13:09:01 mail postfix/smtpd[466]: match_hostname: localhost ~?
>> 127.0.0.0/8
>> Jan 15 13:09:01 mail postfix/smtpd[466]: match_hostaddr: 127.0.0.1 ~?
>> 127.0.0.0/8
>> Jan 15 13:09:01 mail postfix/smtpd[466]: match_list_match:
>> permit_mynetworks: no match
>> culminating in
>> Jan 15 13:09:01 mail postfix/smtpd[466]: NOQUEUE: reject: RCPT from
>> localhost[127.0.0.1]: 554 5.7.1 : Helo command
>> rejected: Host not found; from=
>> to= proto=ESMTP helo=
>>
>>
>> permit_mynetworks should be permitting that, not offering no match.
>
>
> Is amavis running on the local machine? The smtpd process listening for 
> amavis seems unable to match amavis's ip either to local host or to 127.0.0.1.
>
> As as workaround you could change the 'permit_mynetworks' setting on this 
> smtpd process to 'permit'. If you have firewalled port 10025 it should be 
> reasonably safe I think?

Hi Dominic,

So, there was an error in my previous response to Matus - but not a fatal one.

Amavis listens on 10024, and postfix listens on 10025

That means mail comes in on 587, it goes to amavis on 10024 and comes
back on 10025 before going out.

I currently have
#The amavis reciever
127.0.0.1:10025 inet n - - - - smtpd
-o content_filter=
-o local_recipient_maps=
-o relay_recipient_maps=
-o smtpd_restriction_classes=
  -o smtpd_client_restrictions=permit_mynetworks
  -o smtpd_helo_restrictions=permit
-o smtpd_sender_restrictions=
  -o smtpd_relay_restrictions=permit_mynetworks,defer_unauth_destination
   -o 
smtpd_recipient_restrictions=reject_non_fqdn_sender,reject_non_fqdn_recipient
-o mynetworks=127.0.0.0/8,[::1]/128
-o strict_rfc821_envelopes=yes
-o 
receive_override_options=no_unknown_recipient_checks,no_header_body_checks
-o smtp_bind_address=127.0.0.1

and mail is flowing.  I am not happy since the solution to the
original problem has been to make smtpd_helo_restrictions=permit and
even though it's internal we operate a zero-trust policy, and "permit"
is not that.

Thanks for your help, and thanks to Viktor and Matus too.

Regards

Re: Need this rule: Everybody may receive from specific address / a few may receive from any address or domain

[rdquiterio]

Bob Proulx wrote
> rdquiterio wrote:
>> I've been using postfix for several years as a relay but never used it to
>> restrict inbound mail, since it is done by an anti-spam appliance. 
>>
>> But now, we need to implement an inbound rule like this: 
> 
> If inbound mail is already restricted by an anti-spam appliance then
> isn't this going to need to configure the anti-spam appliance for it
> and not your Postfix configuration?  Because otherwise nothing you do
> in Postfix will have any effect.  Right?
> 
> The problem is that I cannot implement both conditions on the anti-spam
> proxy. I can implement the second condition but not both. So, currently,
> the antisspam is allowing any mail to and from my recipients.
> 
> And then if you open up the anti-spam appliance then do you need any
> configuration change for Postfix?  If the defense was there then
> wouldn't adjusting the rules in the anti-spam appliance be enough?
> 
> If you are thinking of removing the anti-spam appliance then setting
> up Postfix is almost like a fresh configuration question of how should
> you set up the full anti-spam in Postfix, right?
> 
>>  1. Everybody on our domain should be allowed to receive email form a
>> specific sender (

> abc@

> ) - i.e. notifications 
>>  2. A few users should be allowed to receive email from any sender or
>> domain. 
> 
> I am not really a Postfix expert.  I myself come here for help.  I am
> but a simple and grateful user of Postfix.  But if it were me I would
> have this following abbreviated configuration.  I'll trim it from mine
> somewhat and then let the actually knowledgeable folks correct my poor
> and feeble attempt at helping.
> 
> Please do not use "abc at xyz.com" as an example email address as that
> is a valid domain name!  Use example.com when needing an example name.
> That way it will not collide with a real live in use valid name.
> 
> In recipient-access file, add your all-spam-to users here:
> 
> abuse@ OK
> postmaster@ OK
> 
> In sender-access file, add your approved sending domains:
> I do NOT approve of this but it is exactly what you asked for!
> 
> example.com OK
> 
> Use 'postmap' to update the two map files above to db names.
> 
> postmap recipient-access
> postmap sender-access
> 
> In main.cf file:
> 
> smtpd_recipient_restrictions =
> permit_mynetworks,
> reject_unauth_destination,
> check_sender_access hash:/etc/postfix/sender-access,
> reject_invalid_hostname,
> reject_non_fqdn_hostname,
> reject_non_fqdn_sender,
> reject_non_fqdn_recipient,
> reject_unknown_sender_domain,
> reject_unknown_recipient_domain,
> check_recipient_access hash:/etc/postfix/recipient-access,
> reject_rbl_client zen.spamhaus.org
> 
> If you are using /etc/postfix elsewhere such as /usr/local/etc/postfix
> then adjust all paths accordingly.
> 
> This does not have all of the configuration I would recommend.  But
> perhaps the minimum amount that I would tolerate.  Perhaps a starting
> place at best.
> 
>> It seems to me that it is possible to achieve with smtpd restrictions,
>> but I
>> cannot figure out how to assemble senders and recipients parameters in
>> main.cf. 
>> 
>> Any help would be appreciated. 
>> 
>> Thanks for your time. 
> 
> Hope this helps!
> Bob





--
Sent from: http://postfix.1071664.n5.nabble.com/Postfix-Users-f2.html

Re: handling long-term unreachable addresses/domains

[Wietse Venema]

Matus UHLAR - fantomas:
> I was thinking about something very similar that address verification does:
> - applied on domains, not individual addresses
> - applied softly, without explicit verification checks
> 
> This would require database of mail domains, and if mail to any domain is
> unreachable for interval longer than maximal_queue_lifetime, mail for/from
> that domain would get rejected and or deferred.
> 
> Until then, mail would be accepted as reachable.
> 
> Any idea if this could be implemented?

Use check_policy_service, reading from a domain status database,
populated with a "postqueue -j" cronjob that looks at the arrival_time
and delay_reason fields. Alternatively the same info could be mined
from logfile records. Again, a cronjob is good enough.

Wietse

Re: phising attacks

[Matus UHLAR - fantomas]

On 15.01.20 15:20, Adam Barnett wrote:

The from address will be, for example

From: Jo Blogs

But the return address and return path would be and different address from what 
Jo Blogs is



I am 99% sure it is a user error, but just wondering if there was anything else 
to be done


unless there's only one Jo Blogs in the world, there's possibility a real Jo
Blogs is sending the mail, just not the one you may think.
Blocking the mail might be bad.

This is why I recommend to verify strange/suspicious requests.
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
My mind is like a steel trap - rusty and illegal in 37 states.

PATCH: milter API function smfi_setsymlist

[Wietse Venema]

Wietse Venema:
> I noticed that the Postfix implementation does the postfix<->milter
> setup while reporting the SMTP connect event.
> This evaluates the connect macros before the postfix<->milter setup
> has a chance to override them.
> 
> Fix would be a some swap of some code.

As implemented in this patch: move the on-the-fly connect before
the macroi evaluation. Should work for Postfix 2.5 and later.

Wietse

diff '--exclude=man' '--exclude=html' '--exclude=README_FILES' 
'--exclude=INSTALL' '--exclude=.indent.pro' '--exclude=Makefile.in' -r -ur 
/var/tmp/postfix-3.5-20200111/HISTORY ./HISTORY
--- /var/tmp/postfix-3.5-20200111/HISTORY   2020-01-11 08:13:31.0 
-0500
+++ ./HISTORY   2020-01-15 09:52:37.283727701 -0500
@@ -24534,3 +24534,10 @@
= smtp:foo.exmple, bar.example". Files: smtp/smtp.c,
smtp/smtp_connect.c, trivial-rewrite/resolve.c, proto/transport,
proto/postconf.proto, global/mail_params.c.
+
+20200115
+
+   Bugfix (introduced: Postfix 2.5): the Milter connect event
+   macros were evaluated before the Milter connection itself
+   had been negottiated. Problem reported by David Bürgin.
+   Files: milter/milter.h, milter/milter.c, milter/milter8.c
diff '--exclude=man' '--exclude=html' '--exclude=README_FILES' 
'--exclude=INSTALL' '--exclude=.indent.pro' '--exclude=Makefile.in' -r -ur 
/var/tmp/postfix-3.5-20200111/src/milter/milter8.c ./src/milter/milter8.c
--- /var/tmp/postfix-3.5-20200111/src/milter/milter8.c  2018-11-27 
19:30:23.0 -0500
+++ ./src/milter/milter8.c  2020-01-15 09:32:31.488633919 -0500
@@ -1918,15 +1918,6 @@
 #define STR_NE(x,y)(strcmp((x), (y)) != 0)
 
 /*
- * XXX Sendmail 8 libmilter closes the MTA-to-filter socket when it finds
- * out that the SMTP client has disconnected. Because of this, Postfix
- * has to open a new MTA-to-filter socket for each SMTP client.
- */
-#ifdef LIBMILTER_AUTO_DISCONNECT
-milter8_connect(milter);
-#endif
-
-/*
  * Report the event.
  */
 switch (milter->state) {
@@ -2835,6 +2826,10 @@
 
 /*
  * Fill in the structure. Note: all strings must be copied.
+ * 
+ * XXX Sendmail 8 libmilter closes the MTA-to-filter socket when it finds
+ * out that the SMTP client has disconnected. Because of this, Postfix
+ * has to open a new MTA-to-filter socket for each SMTP client.
  */
 milter = (MILTER8 *) mymalloc(sizeof(*milter));
 milter->m.name = mystrdup(name);
@@ -2842,6 +2837,11 @@
 milter->m.next = 0;
 milter->m.parent = parent;
 milter->m.macros = 0;
+#ifdef LIBMILTER_AUTO_DISCONNECT
+milter->m.connect_on_demand = (void (*) (struct MILTER *)) milter8_connect;
+#else
+milter->m.connect_on_demand = 0;
+#endif
 milter->m.conn_event = milter8_conn_event;
 milter->m.helo_event = milter8_helo_event;
 milter->m.mail_event = milter8_mail_event;
diff '--exclude=man' '--exclude=html' '--exclude=README_FILES' 
'--exclude=INSTALL' '--exclude=.indent.pro' '--exclude=Makefile.in' -r -ur 
/var/tmp/postfix-3.5-20200111/src/milter/milter.c ./src/milter/milter.c
--- /var/tmp/postfix-3.5-20200111/src/milter/milter.c   2017-02-21 
17:32:57.0 -0500
+++ ./src/milter/milter.c   2020-01-15 09:37:43.834235726 -0500
@@ -417,6 +417,8 @@
 if (msg_verbose)
msg_info("report connect to all milters");
 for (resp = 0, m = milters->milter_list; resp == 0 && m != 0; m = m->next) 
{
+   if (m->connect_on_demand != 0)
+   m->connect_on_demand(m);
any_macros = MILTER_MACRO_EVAL(global_macros, m, milters, conn_macros);
resp = m->conn_event(m, client_name, client_addr, client_port,
 addr_family, any_macros);
diff '--exclude=man' '--exclude=html' '--exclude=README_FILES' 
'--exclude=INSTALL' '--exclude=.indent.pro' '--exclude=Makefile.in' -r -ur 
/var/tmp/postfix-3.5-20200111/src/milter/milter.h ./src/milter/milter.h
--- /var/tmp/postfix-3.5-20200111/src/milter/milter.h   2016-06-11 
18:17:03.0 -0400
+++ ./src/milter/milter.h   2020-01-15 09:32:31.498634162 -0500
@@ -35,6 +35,7 @@
 struct MILTER *next;   /* linkage */
 struct MILTERS *parent;/* parent information */
 struct MILTER_MACROS *macros;  /* private macros */
+void(*connect_on_demand) (struct MILTER *);
 const char *(*conn_event) (struct MILTER *, const char *, const char *, 
const char *, unsigned, ARGV *);
 const char *(*helo_event) (struct MILTER *, const char *, int, ARGV *);
 const char *(*mail_event) (struct MILTER *, const char **, ARGV *);

Re: phising attacks

[Adam Barnett]

Thanks, i will look into it 


-- 
__ 
Adam Barnett 
Systems Engineer 
Double Negative 
160 Great Portland Street,W1W 5QA 
T: 020-7268-5000 
[ http://www.dneg.com/ | www.dneg.com ] 
__

- Original Message -
| From: "Dominic Raferd" 
| To: "Postfix users" 
| Sent: Wednesday, 15 January, 2020 15:33:33
| Subject: Re: phising attacks

| On Wed, 15 Jan 2020 at 15:20, Adam Barnett  wrote:
| 
|> The from address will be, for example
|>
|> From: Jo Blogs
|>
|> But the return address and return path would be and different address from
|> what Jo Blogs is
|>
|>
|> I am 99% sure it is a user error, but just wondering if there was anything
|> else to be done
|> __
|>
|> - Original Message -
|> | From: "Dominic Raferd" 
|> | To: "Postfix users" 
|> | Sent: Wednesday, 15 January, 2020 15:15:30
|> | Subject: Re: phising attacks
|>
|> | On Wed, 15 Jan 2020 at 15:09, Adam Barnett  wrote:
|> |
|> |> Hi Postfix Peeps
|> |> We seem to be getting more phishing attacks that are being clever. The
|> |> address looks like it someone internal but the from address is not that
|> |> person.
|> |> Any suggestions postfix or otherwise to help with these
|> |>
|> |
|> | When you say 'looks like it someone internal' what *exactly* do you mean?
|>
| 
| There is plenty that can be done with header_checks (based on one header at
| a time) but it depends on exactly what you are seeing, and you haven't
| provided a full From header. Is the email address in the From header being
| faked as well as the text, or only the text? For multi-header rules (e.g.
| combination of From: and Reply-To:) you need something like postfwd /
| spamassassin / mimedefang(?)
| 
| I don't see actual email addresses of our domains being faked in From
| headers, but that's because we use DMARC with p=reject. But I do see the
| text being faked, including inserting our names or a fake email address
| (i.e. one of ours) before the real (foreign) address. I trap these.

Re: phising attacks

[Dominic Raferd]

On Wed, 15 Jan 2020 at 15:20, Adam Barnett  wrote:

> The from address will be, for example
>
> From: Jo Blogs
>
> But the return address and return path would be and different address from
> what Jo Blogs is
>
>
> I am 99% sure it is a user error, but just wondering if there was anything
> else to be done
> __
>
> - Original Message -
> | From: "Dominic Raferd" 
> | To: "Postfix users" 
> | Sent: Wednesday, 15 January, 2020 15:15:30
> | Subject: Re: phising attacks
>
> | On Wed, 15 Jan 2020 at 15:09, Adam Barnett  wrote:
> |
> |> Hi Postfix Peeps
> |> We seem to be getting more phishing attacks that are being clever. The
> |> address looks like it someone internal but the from address is not that
> |> person.
> |> Any suggestions postfix or otherwise to help with these
> |>
> |
> | When you say 'looks like it someone internal' what *exactly* do you mean?
>

There is plenty that can be done with header_checks (based on one header at
a time) but it depends on exactly what you are seeing, and you haven't
provided a full From header. Is the email address in the From header being
faked as well as the text, or only the text? For multi-header rules (e.g.
combination of From: and Reply-To:) you need something like postfwd /
spamassassin / mimedefang(?)

I don't see actual email addresses of our domains being faked in From
headers, but that's because we use DMARC with p=reject. But I do see the
text being faked, including inserting our names or a fake email address
(i.e. one of ours) before the real (foreign) address. I trap these.

Re: phising attacks

[Adam Barnett]

The from address will be, for example 

From: Jo Blogs

But the return address and return path would be and different address from what 
Jo Blogs is 


I am 99% sure it is a user error, but just wondering if there was anything else 
to be done

Thanks



-- 
__ 
Adam Barnett 
Systems Engineer 
Double Negative 
160 Great Portland Street,W1W 5QA 
T: 020-7268-5000 
[ http://www.dneg.com/ | www.dneg.com ] 
__

- Original Message -
| From: "Dominic Raferd" 
| To: "Postfix users" 
| Sent: Wednesday, 15 January, 2020 15:15:30
| Subject: Re: phising attacks

| On Wed, 15 Jan 2020 at 15:09, Adam Barnett  wrote:
| 
|> Hi Postfix Peeps
|> We seem to be getting more phishing attacks that are being clever. The
|> address looks like it someone internal but the from address is not that
|> person.
|> Any suggestions postfix or otherwise to help with these
|>
| 
| When you say 'looks like it someone internal' what *exactly* do you mean?

Re: phising attacks

[Dominic Raferd]

On Wed, 15 Jan 2020 at 15:09, Adam Barnett  wrote:

> Hi Postfix Peeps
> We seem to be getting more phishing attacks that are being clever. The
> address looks like it someone internal but the from address is not that
> person.
> Any suggestions postfix or otherwise to help with these
>

When you say 'looks like it someone internal' what *exactly* do you mean?

Re: phising attacks

[Matus UHLAR - fantomas]

On 15.01.20 15:08, Adam Barnett wrote:

We seem to be getting more phishing attacks that are being clever. The address 
looks like it someone internal but the from address is not that person.

Any suggestions postfix or otherwise to help with these


except standard anti-spam and anti-spoofing measures?
Hardly any. Is possible, teach you users to verify strange requests.

--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
I just got lost in thought. It was unfamiliar territory.

phising attacks

[Adam Barnett]

Hi Postfix Peeps

We seem to be getting more phishing attacks that are being clever. The address 
looks like it someone internal but the from address is not that person. 

Any suggestions postfix or otherwise to help with these

Thanks
Adam 

Re: Postfix HELO checks

[Dominic Raferd]

On Wed, 15 Jan 2020 at 13:36, Simon B  wrote:

> On Wed, 15 Jan 2020 at 13:40, Matus UHLAR - fantomas 
> wrote:
> >
> > >> On Mon, Jan 13, 2020 at 06:25:27PM +0100, Simon B wrote:
> > >> > > > >> >Since upgrading to 2.11 yesterday (yes, I am on a path to
> move up
> > >> > > > >> >through debian versions), all mail coming in on
> > >> > > > >> >postfix/submission/smtpd is being rejected by the domain
> check in that
> > >> > > > >> >file, even though the user is sasl authenticated.
> >
> > >On Mon, 13 Jan 2020 at 18:44, Viktor Dukhovni
> > > wrote:
> > >> Note, Postfix 2.11 (actually 2.10 IIRC) adds
> "smtpd_relay_restrictions",
> > >> which you don't override in the submission service definition:
> >
> > On 15.01.20 13:19, Simon B wrote:
> > >Cause and effect in one simple sentence - thanks Viktor!
> >
> > if you use debian, the default smtpd_relay_restrictions should contain:
> >
> > smtpd_relay_restrictions=permit_mynetworks permit_sasl_authenticated
> defer_unauth_destination
>
> That results in this
> Jan 15 13:32:53 mail postfix/smtpd[743]: NOQUEUE: reject: RCPT from
> localhost[127.0.0.1]: 451 4.3.5 Server configuration error;
>
> > which is the default value. It's added in postfix postinst script.
> >
> > ...unless you have overridden it, in such case it contains what you put
> > there.
> >
> > >Now looks like this...
> > >
> > > 10 submission inet n   -   n   -   -   smtpd
> > > 11   -o syslog_name=postfix/submission
> >
> > >Which seems to have solved the problem - or at least just kicked it
> > >down the road.  Now there's a slightly different format of the error
> > >when receiving mail from the amavis filter...
> > >
> > >Jan 15 11:39:31 mail postfix/smtpd[31588]: connect from
> localhost[127.0.0.1]
> > >Jan 15 11:39:31 mail postfix/smtpd[31588]: NOQUEUE: reject: RCPT from
> > >localhost[127.0.0.1]: 554 5.7.1 : Helo command
> > >rejected: Host not found; from= to=<
> > >simo...@example.com> proto=ESMTP helo=
> >
> > note that this says "postfix/smtpd" and thus it's not related to
> master.cf
> > definition of submission above, then would say "postfix/submission/smtpd"
>
> Correct.  The submission problem is now solved.  The problem is now
> receiving mail back from amavis.
>
> > >Jan 15 11:39:31 mail amavisd-new[2303]: (02303-14) smtp resp to RCPT
> > >(pip) (): 554 5.7.1 : Helo
> > >command rejected: Host not found
> >
> > >Despite the fact that I changed those receiver settings in master.cf
> to:
> > >
> > >118 #The amavis reciever
> > >119 127.0.0.1:10025 inet n - - - - smtpd
> > >120 -o content_filter=
> > >121 -o local_recipient_maps=
> > >122 -o relay_recipient_maps=
> > >123 -o smtpd_restriction_classes=
> > >124   -o
> smtpd_client_restrictions=permit_mynetworks,reject_plaintext_session
> > >125   -o smtpd_helo_restrictions=permit_mynetworks
> > >126 -o smtpd_sender_restrictions=
> > >127 -o smtpd_recipient_restrictions=permit_mynetworks,reject
> > >128 -o mynetworks=127.0.0.0/8
> > >129 -o strict_rfc821_envelopes=yes
> > >130 -o
> receive_override_options=no_unknown_recipient_checks,no_header_body_checks
> > >131 -o smtp_bind_address=127.0.0.1
> > >
> > >At the moment nothing is going through amavis in either direction, so
> > >that's a problem...
> >
> > are you sure amavis sends mail through port 10025?
>
> Hi Matus,
>
> Yes, very sure.
>
> if I turn on -v logging for that hop, I am concerned about these lines
> in the log.
>
> Jan 15 13:09:01 mail postfix/smtpd[466]: < localhost[127.0.0.1]: EHLO
> amavisd.localhost
> Jan 15 13:09:01 mail postfix/smtpd[466]: match_list_match: localhost: no
> match
> Jan 15 13:09:01 mail postfix/smtpd[466]: match_list_match: 127.0.0.1: no
> match
> and
> Jan 15 13:09:01 mail postfix/smtpd[466]: generic_checks:
> name=permit_mynetworks
> Jan 15 13:09:01 mail postfix/smtpd[466]: permit_mynetworks: localhost
> 127.0.0.1
> Jan 15 13:09:01 mail postfix/smtpd[466]: match_hostname: localhost ~?
> 127.0.0.0/8
> Jan 15 13:09:01 mail postfix/smtpd[466]: match_hostaddr: 127.0.0.1 ~?
> 127.0.0.0/8
> Jan 15 13:09:01 mail postfix/smtpd[466]: match_list_match:
> permit_mynetworks: no match
> culminating in
> Jan 15 13:09:01 mail postfix/smtpd[466]: NOQUEUE: reject: RCPT from
> localhost[127.0.0.1]: 554 5.7.1 : Helo command
> rejected: Host not found; from=
> to= proto=ESMTP helo=
>
>
> permit_mynetworks should be permitting that, not offering no match.
>

Is amavis running on the local machine? The smtpd process listening for
amavis seems unable to match amavis's ip either to local host or to
127.0.0.1.

As as workaround you could change the 'permit_mynetworks' setting on this
smtpd process to 'permit'. If you have firewalled port 10025 it should be
reasonably safe I think?

Re: Port 25 closed on bulk sending servers

[Bill Cole]

On 15 Jan 2020, at 7:56, Sam Tuke wrote:

I noticed that newsletters which I receive from large firms are 
typically sent from servers which have port 25 closed.


Is it common practice to close port 25 on bulk sending servers?


Yes, and not only for bulk sending servers.

Should we do this for Postfix servers which serve the same role? 
What's the advantage?


It is quite common for inbound and outbound email to be handled by 
separate systems. In environments using internal mail servers that 
aren't good at spam exclusion and/or have a general pattern of chronic 
insecurity (e.g. Exchange) it is not uncommon to have them sending 
outbound mail from behind a very strict firewall and/or NAT with no 
listeners exposed to the world and to receive via a more robust platform 
for dealing with mail from the Internet.


Maybe the MTAs that such senders use are so customised as to be 
capable of only sending, not receiving, mail?


There's some of that for very large senders, but in the modern age of 
almost everything being virtual, it is also just simpler to disperse 
essentially independent functions onto independent systems, with each 
specifically configured and scaled to their role. In DNS this has meant 
splitting authoritative servers and resolvers. In email this has meant a 
more diverse split, with public MXs, initial mail submission handlers, 
outbound queue handlers, mailstore management & access, and internal 
distribution potentially being autonomous systems. This can simplify the 
configuration of each system and make securing them less challenging.


--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not For Hire (currently)

Re: Port 25 closed on bulk sending servers

[@lbutlr]

On 15 Jan 2020, at 05:56, Sam Tuke  wrote:
> I noticed that newsletters which I receive from large firms are typically 
> sent from servers which have port 25 closed.

And this is an issue why?

> Is it common practice to close port 25 on bulk sending servers? Should we do 
> this for Postfix servers which serve the same role? What's the advantage?

It is common to not have port 25 open on any machine that does not receive mail.

> Maybe the MTAs that such senders use are so customised as to be capable of 
> only sending, not receiving, mail?

That is not “highly customize”; that is a very normal setup for large installs.


-- 
"Are you pondering what I'm pondering?"
"Well, I think so hiccup, but Kevin Costner with an English accent?”

Re: Postfix HELO checks

[Simon B]

On Wed, 15 Jan 2020 at 13:40, Matus UHLAR - fantomas  wrote:
>
> >> On Mon, Jan 13, 2020 at 06:25:27PM +0100, Simon B wrote:
> >> > > > >> >Since upgrading to 2.11 yesterday (yes, I am on a path to move up
> >> > > > >> >through debian versions), all mail coming in on
> >> > > > >> >postfix/submission/smtpd is being rejected by the domain check 
> >> > > > >> >in that
> >> > > > >> >file, even though the user is sasl authenticated.
>
> >On Mon, 13 Jan 2020 at 18:44, Viktor Dukhovni
> > wrote:
> >> Note, Postfix 2.11 (actually 2.10 IIRC) adds "smtpd_relay_restrictions",
> >> which you don't override in the submission service definition:
>
> On 15.01.20 13:19, Simon B wrote:
> >Cause and effect in one simple sentence - thanks Viktor!
>
> if you use debian, the default smtpd_relay_restrictions should contain:
>
> smtpd_relay_restrictions=permit_mynetworks permit_sasl_authenticated 
> defer_unauth_destination

That results in this
Jan 15 13:32:53 mail postfix/smtpd[743]: NOQUEUE: reject: RCPT from
localhost[127.0.0.1]: 451 4.3.5 Server configuration error;

> which is the default value. It's added in postfix postinst script.
>
> ...unless you have overridden it, in such case it contains what you put
> there.
>
> >Now looks like this...
> >
> > 10 submission inet n   -   n   -   -   smtpd
> > 11   -o syslog_name=postfix/submission
>
> >Which seems to have solved the problem - or at least just kicked it
> >down the road.  Now there's a slightly different format of the error
> >when receiving mail from the amavis filter...
> >
> >Jan 15 11:39:31 mail postfix/smtpd[31588]: connect from localhost[127.0.0.1]
> >Jan 15 11:39:31 mail postfix/smtpd[31588]: NOQUEUE: reject: RCPT from
> >localhost[127.0.0.1]: 554 5.7.1 : Helo command
> >rejected: Host not found; from= to=<
> >simo...@example.com> proto=ESMTP helo=
>
> note that this says "postfix/smtpd" and thus it's not related to master.cf
> definition of submission above, then would say "postfix/submission/smtpd"

Correct.  The submission problem is now solved.  The problem is now
receiving mail back from amavis.

> >Jan 15 11:39:31 mail amavisd-new[2303]: (02303-14) smtp resp to RCPT
> >(pip) (): 554 5.7.1 : Helo
> >command rejected: Host not found
>
> >Despite the fact that I changed those receiver settings in master.cf to:
> >
> >118 #The amavis reciever
> >119 127.0.0.1:10025 inet n - - - - smtpd
> >120 -o content_filter=
> >121 -o local_recipient_maps=
> >122 -o relay_recipient_maps=
> >123 -o smtpd_restriction_classes=
> >124   -o smtpd_client_restrictions=permit_mynetworks,reject_plaintext_session
> >125   -o smtpd_helo_restrictions=permit_mynetworks
> >126 -o smtpd_sender_restrictions=
> >127 -o smtpd_recipient_restrictions=permit_mynetworks,reject
> >128 -o mynetworks=127.0.0.0/8
> >129 -o strict_rfc821_envelopes=yes
> >130 -o 
> >receive_override_options=no_unknown_recipient_checks,no_header_body_checks
> >131 -o smtp_bind_address=127.0.0.1
> >
> >At the moment nothing is going through amavis in either direction, so
> >that's a problem...
>
> are you sure amavis sends mail through port 10025?

Hi Matus,

Yes, very sure.

if I turn on -v logging for that hop, I am concerned about these lines
in the log.

Jan 15 13:09:01 mail postfix/smtpd[466]: < localhost[127.0.0.1]: EHLO
amavisd.localhost
Jan 15 13:09:01 mail postfix/smtpd[466]: match_list_match: localhost: no match
Jan 15 13:09:01 mail postfix/smtpd[466]: match_list_match: 127.0.0.1: no match
and
Jan 15 13:09:01 mail postfix/smtpd[466]: generic_checks: name=permit_mynetworks
Jan 15 13:09:01 mail postfix/smtpd[466]: permit_mynetworks: localhost 127.0.0.1
Jan 15 13:09:01 mail postfix/smtpd[466]: match_hostname: localhost ~?
127.0.0.0/8
Jan 15 13:09:01 mail postfix/smtpd[466]: match_hostaddr: 127.0.0.1 ~?
127.0.0.0/8
Jan 15 13:09:01 mail postfix/smtpd[466]: match_list_match:
permit_mynetworks: no match
culminating in
Jan 15 13:09:01 mail postfix/smtpd[466]: NOQUEUE: reject: RCPT from
localhost[127.0.0.1]: 554 5.7.1 : Helo command
rejected: Host not found; from=
to= proto=ESMTP helo=


permit_mynetworks should be permitting that, not offering no match.

Re: handling long-term unreachable addresses/domains

[Matus UHLAR - fantomas]

On 09.01.20 17:09, Matus UHLAR - fantomas wrote:

on a few mail servers/gateways, we receive mail from domains that are
unreachable for mail delivery on a long-term basis.

besides spammers, there are companies that send mail from domains which
don't have MX records, and A records point to servers without mail service
running.

I would like to detect this kind of domains and block them.
Ideally, not immediately, but when e.g. domain is inaccessible for a given
time, e.g. when mail starts being returned.

Is something similar possible now?


I was thinking about something very similar that address verification does:
- applied on domains, not individual addresses
- applied softly, without explicit verification checks

This would require database of mail domains, and if mail to any domain is
unreachable for interval longer than maximal_queue_lifetime, mail for/from
that domain would get rejected and or deferred.

Until then, mail would be accepted as reachable.

Any idea if this could be implemented?

--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Microsoft dick is soft to do no harm

Re: Port 25 closed on bulk sending servers

[Sven Schwedas]

> Maybe the MTAs that such senders use are so customised as to be capable
> of only sending, not receiving, mail?

Usually, yes, these systems are typically decoupled from the firms'
"regular" emailing infrastructure (maintained by different business
units etc.) and aren't interested in receiving emails: Bulk email often
doesn't care about replies, and tends to be sent on behalf of external
clients, who are in the Reply-To/From header /if/ they care about
getting replies.

Those headers are also often completely spoofed for spam emails, so
testing if /that/ email server is reachable on port 25 doesn't tell you
much either.

-- 
Mit freundlichen Grüßen, / Best Regards,
Sven Schwedas, Systemadministrator
✉ sven.schwe...@tao.at | ☎ +43 680 301 7167
TAO Digital   | Teil der TAO Beratungs- & Management GmbH
Lendplatz 45  | FN 213999f/Klagenfurt, FB-Gericht Villach
A8020 Graz| https://www.tao-digital.at



signature.asc
Description: OpenPGP digital signature

Re: Port 25 closed on bulk sending servers

[Matus UHLAR - fantomas]

On 15.01.20 12:56, Sam Tuke wrote:

I noticed that newsletters which I receive from large firms are typically sent 
from servers which have port 25 closed.


I guess they are not mail servers. Not all servers have to receive mail.
Many companies have different servers for incoming mail than for outgoing
mail, webservers or whatever.


Is it common practice to close port 25 on bulk sending servers?  Should we
do this for Postfix servers which serve the same role?  What's the
advantage?

Maybe the MTAs that such senders use are so customised as to be capable of
only sending, not receiving, mail?


I have asked about very similar issue a week ago. Will bump.

--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
2B|!2B, that's a question!

Port 25 closed on bulk sending servers

[Sam Tuke]

I noticed that newsletters which I receive from large firms are typically sent 
from servers which have port 25 closed.

Is it common practice to close port 25 on bulk sending servers? Should we do 
this for Postfix servers which serve the same role? What's the advantage?

Maybe the MTAs that such senders use are so customised as to be capable of only 
sending, not receiving, mail?

Thanks!

Sam.

Re: Is the milter API function smfi_setsymlist supported?

[Wietse Venema]

David B?rgin:
> On 15/01/2020 13:32, Wietse Venema wrote:> Please try any OTHER stage than 
> connect. It might be a bug 
> > that exists only in the connect handler. You would help
> > narrow down the search for me.
> 
> You?re right, I just tried requesting _ for the data stage and that does
> work!

Thanks for checking that.

I noticed that the Postfix implementation does the postfix<->milter
setup while reporting the SMTP connect event.

This evaluates the connect macros before the postfix<->milter setup
has a chance to override them.

Fix would be a some swap of some code.

Wietse

Re: Is the milter API function smfi_setsymlist supported?

[David Bürgin]

On 15/01/2020 13:32, Wietse Venema wrote:> Please try any OTHER stage than 
connect. It might be a bug 
> that exists only in the connect handler. You would help
> narrow down the search for me.

You’re right, I just tried requesting _ for the data stage and that does
work!

I have to take a break from this, sorry. And thanks for looking.

Re: Postfix HELO checks

[Matus UHLAR - fantomas]

On Mon, Jan 13, 2020 at 06:25:27PM +0100, Simon B wrote:
> > > >> >Since upgrading to 2.11 yesterday (yes, I am on a path to move up
> > > >> >through debian versions), all mail coming in on
> > > >> >postfix/submission/smtpd is being rejected by the domain check in that
> > > >> >file, even though the user is sasl authenticated.



On Mon, 13 Jan 2020 at 18:44, Viktor Dukhovni
 wrote:

Note, Postfix 2.11 (actually 2.10 IIRC) adds "smtpd_relay_restrictions",
which you don't override in the submission service definition:


On 15.01.20 13:19, Simon B wrote:

Cause and effect in one simple sentence - thanks Viktor!


if you use debian, the default smtpd_relay_restrictions should contain:

smtpd_relay_restrictions=permit_mynetworks permit_sasl_authenticated 
defer_unauth_destination

which is the default value. It's added in postfix postinst script.

...unless you have overridden it, in such case it contains what you put
there.


Now looks like this...

10 submission inet n   -   n   -   -   smtpd
11   -o syslog_name=postfix/submission



Which seems to have solved the problem - or at least just kicked it
down the road.  Now there's a slightly different format of the error
when receiving mail from the amavis filter...

Jan 15 11:39:31 mail postfix/smtpd[31588]: connect from localhost[127.0.0.1]
Jan 15 11:39:31 mail postfix/smtpd[31588]: NOQUEUE: reject: RCPT from
localhost[127.0.0.1]: 554 5.7.1 : Helo command
rejected: Host not found; from= to=<
simo...@example.com> proto=ESMTP helo=


note that this says "postfix/smtpd" and thus it's not related to master.cf
definition of submission above, then would say "postfix/submission/smtpd"


Jan 15 11:39:31 mail amavisd-new[2303]: (02303-14) smtp resp to RCPT
(pip) (): 554 5.7.1 : Helo
command rejected: Host not found



Despite the fact that I changed those receiver settings in master.cf to:

118 #The amavis reciever
119 127.0.0.1:10025 inet n - - - - smtpd
120 -o content_filter=
121 -o local_recipient_maps=
122 -o relay_recipient_maps=
123 -o smtpd_restriction_classes=
124   -o smtpd_client_restrictions=permit_mynetworks,reject_plaintext_session
125   -o smtpd_helo_restrictions=permit_mynetworks
126 -o smtpd_sender_restrictions=
127 -o smtpd_recipient_restrictions=permit_mynetworks,reject
128 -o mynetworks=127.0.0.0/8
129 -o strict_rfc821_envelopes=yes
130 -o 
receive_override_options=no_unknown_recipient_checks,no_header_body_checks
131 -o smtp_bind_address=127.0.0.1

At the moment nothing is going through amavis in either direction, so
that's a problem...


are you sure amavis sends mail through port 10025?


--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Christian Science Programming: "Let God Debug It!".

Re: Is the milter API function smfi_setsymlist supported?

[Wietse Venema]

David B?rgin:
> If someone wants to try ? Make sure you have libmilter installed.
> Compile and run:
> 
> c99 -Wall nosetsymlist.c -lmilter -o nosetsymlist
> ./nosetsymlist
> 
> Enable in /etc/postfix/main.cf with:
> 
> smtpd_milters = inet:localhost:3000
> 
> Then both requested macros, _ and {client_port}, are *not* available
> during connect. If I request these macros in /etc/postfix/main.cf with
> 
> milter_connect_macros = _ {client_port}
> 
> then they *are* available and do get printed. Either smfi_setsymlist
> doesn?t do anything, or ? perhaps more likely ? I?m making a mistake!
> Very grateful for any hints.

Please try any OTHER stage than connect. It might be a bug 
that exists only in the connect handler. You would help
narrow down the search for me.

Wietse

Re: Postfix HELO checks

[Simon B]

On Mon, 13 Jan 2020 at 18:44, Viktor Dukhovni
 wrote:
>
> On Mon, Jan 13, 2020 at 06:25:27PM +0100, Simon B wrote:
>
> > > > >> >Since upgrading to 2.11 yesterday (yes, I am on a path to move up
> > > > >> >through debian versions), all mail coming in on
> > > > >> >postfix/submission/smtpd is being rejected by the domain check in 
> > > > >> >that
> > > > >> >file, even though the user is sasl authenticated.
>
> Note, Postfix 2.11 (actually 2.10 IIRC) adds "smtpd_relay_restrictions",
> which you don't override in the submission service definition:

Cause and effect in one simple sentence - thanks Viktor!

> > submission inet n   -   n   -   -   smtpd
> >-o syslog_name=postfix/submission
> >-o smtpd_delay_reject=yes
> > #   -o receive_override_options=no_address_mappings
> >-o always_add_missing_headers=yes
> >-o content_filter=dksign:[127.0.0.1]:10028
> >-o smtpd_enforce_tls=yes
> >-o smtpd_sasl_auth_enable=yes
> >-o smtpd_tls_security_level=encrypt
> >-o smtpd_tls_auth_only=yes
> >-o 
> > smtpd_recipient_restrictions=reject_non_fqdn_sender,reject_non_fqdn_recipient,permit_sasl_authenticated,reject
>
> But you also don't override, "smtpd_helo_restrictions", ...

Thanks for the additional hint.

> The boilerplate commented submission service in recent upstream Postfix
> master.cf files reads:
>
> #submission inet n   -   n   -   -   smtpd
> #  -o syslog_name=postfix/submission
> #  -o smtpd_tls_security_level=encrypt
> #  -o smtpd_sasl_auth_enable=yes
> #  -o smtpd_tls_auth_only=yes
> #  -o smtpd_reject_unlisted_recipient=no
> #  -o smtpd_client_restrictions=$mua_client_restrictions
> #  -o smtpd_helo_restrictions=$mua_helo_restrictions
> #  -o smtpd_sender_restrictions=$mua_sender_restrictions
> #  -o smtpd_recipient_restrictions=
> #  -o smtpd_relay_restrictions=permit_sasl_authenticated,reject
> #  -o milter_macro_daemon_name=ORIGINATING
>
> Yours should look substantially similar (sans comments):

Now looks like this...

 10 submission inet n   -   n   -   -   smtpd
 11   -o syslog_name=postfix/submission
 12   -o smtpd_tls_security_level=encrypt
 13   -o smtpd_sasl_auth_enable=yes
 14   -o smtpd_tls_auth_only=yes
 15-o smtpd_enforce_tls=yes
 16-o smtpd_delay_reject=yes
 17-o always_add_missing_headers=yes
 18-o content_filter=dksign:[127.0.0.1]:10028
 19   -o smtpd_reject_unlisted_recipient=no
 20-o 
smtpd_recipient_restrictions=reject_non_fqdn_sender,reject_non_fqdn_recipient,permit_sasl_authenticated,reject
 21   -o 
smtpd_client_restrictions=permit_mynetworks,permit_sasl_authenticated,reject_plaintext_session,reject
 22   -o smtpd_helo_restrictions=permit_mynetworks,reject_invalid_helo_hostname
 23   -o smtpd_sender_restrictions=reject_non_fqdn_sender
 24   -o smtpd_relay_restrictions=permit_sasl_authenticated,reject
 25   -o milter_macro_daemon_name=ORIGINATING

Which seems to have solved the problem - or at least just kicked it
down the road.  Now there's a slightly different format of the error
when receiving mail from the amavis filter...

Jan 15 11:39:31 mail postfix/smtpd[31588]: connect from localhost[127.0.0.1]
Jan 15 11:39:31 mail postfix/smtpd[31588]: NOQUEUE: reject: RCPT from
localhost[127.0.0.1]: 554 5.7.1 : Helo command
rejected: Host not found; from= to=<
simo...@example.com> proto=ESMTP helo=
Jan 15 11:39:31 mail amavisd-new[2303]: (02303-14) smtp resp to RCPT
(pip) (): 554 5.7.1 : Helo
command rejected: Host not found
Jan 15 11:39:31 mail amavisd-new[2303]: (02303-14) Negative SMTP resp.
to DATA: 554 5.5.1 Error: no valid recipients
Jan 15 11:39:31 mail postfix/smtpd[31588]: disconnect from localhost[127.0.0.1]
Jan 15 11:39:31 mail amavisd-new[2303]: (02303-14) (!)kTBsiMtC7PPJ FWD
from  -> , BODY=7BIT 554 5.7.1
from MTA(smtp:[127.0.0.1]:10025): 554 5.7.1 :
Helo command rejected: Host not found
Jan 15 11:39:31 mail amavisd-new[2303]: (02303-14) Blocked MTA-BLOCKED
{RejectedInbound}, [127.0.0.1] [217.110.53.130]  ->
, Message-ID:
<20200115113913.horde.vu0wmb4khzfc85v7hddg...@webmail.example.net>,
mail_id: kTBsiMtC7PPJ, Hits: -5.2, size: 1093, 5595 ms
Jan 15 11:39:31 mail amavisd-new[2303]: (02303-14) TIMING-SA total
5466 ms - parse: 1.86 (0.0%), extract_message_metadata: 3.8 (0.1%),
get_uri_detail_list: 0.31 (0.0%), tests_pri_-1000: 4.5 (0.1%),
tests_pri_-950: 1.14 (0.0%), tests_pri_-900: 0.91 (0.0%),
tests_pri_-400: 77 (1.4%), check_bayes: 76 (1.4%), b_tie_ro: 1.69
(0.0%), b_tokenize: 3.1 (0.1%), b_tok_get_all: 3.9 (0.1%),
b_comp_prob: 1.50 (0.0%), b_tok_touch_all: 63 (1.2%), b_finish: 0.65
(0.0%), tests_pri_0: 5223 (95.6%), check_spf: 0.23 (0.0%),
check_dkim_adsp: 3.3 (0.1%), check_dcc: 138 (2.5%), check_razor2: 5005
(91.6%), check_pyzor: 40 (0.7%), tests_pri_500: 3.1 (0.1%), learn: 141
(2.6%), b_learn: 140 (2.6%), b_tie_rw: 1.85 (0.0%), b_count_change: 99
(1.8%), get_report: 0.59 (0.0%)
Jan 15 11:39:31 mail 

Re: Is the milter API function smfi_setsymlist supported?

[David Bürgin]

If someone wants to try … Make sure you have libmilter installed.
Compile and run:

c99 -Wall nosetsymlist.c -lmilter -o nosetsymlist
./nosetsymlist

Enable in /etc/postfix/main.cf with:

smtpd_milters = inet:localhost:3000

Then both requested macros, _ and {client_port}, are *not* available
during connect. If I request these macros in /etc/postfix/main.cf with

milter_connect_macros = _ {client_port}

then they *are* available and do get printed. Either smfi_setsymlist
doesn’t do anything, or – perhaps more likely – I’m making a mistake!
Very grateful for any hints.


#include 
#include 
#include "libmilter/mfapi.h"

sfsistat test_negotiate(
SMFICTX *ctx,
unsigned long f0, unsigned long f1, unsigned long f2, unsigned long f3,
unsigned long *pf0, unsigned long *pf1, unsigned long *pf2, unsigned long 
*pf3
) {
*pf0 = *pf1 = *pf2 = *pf3 = 0;

int status = smfi_setsymlist(ctx, SMFIM_CONNECT, "_ {client_port}");
assert(status == MI_SUCCESS);

return SMFIS_CONTINUE;
}

sfsistat test_connect(SMFICTX *ctx, char *hostname, struct sockaddr *hostaddr) {
char *_macro = smfi_getsymval(ctx, "_");
printf("_: %s\n", _macro == NULL ? "NULL" : _macro);

char *cpmacro = smfi_getsymval(ctx, "{client_port}");
printf("{client_port}: %s\n", cpmacro == NULL ? "NULL" : cpmacro);

return SMFIS_CONTINUE;
}

int main() {
int connstatus = smfi_setconn("inet:3000@localhost");
assert(connstatus == MI_SUCCESS);

int regstatus = smfi_register((struct smfiDesc) {
.xxfi_name = "nosetsymlist",
.xxfi_version = SMFI_VERSION,
.xxfi_connect = test_connect,
.xxfi_negotiate = test_negotiate,
});
assert(regstatus == MI_SUCCESS);

return smfi_main();
}

Re: broken haproxy crc32 support

[Willy Tarreau]

Hi Wietse,

I have a good news for you. While fixing the bug and auditing all of
its extent, I noticed that the PROXY protocol doesn't use the CRC32
but CRC32c (the Castagnoli variant), which is *not* affected by the
signedness bug :

crc = (crc >> 8) ^ crctable[(crc ^ (*buf++)) & 0xff];

I suspect that during your tests you might have used the hash_crc32()
function to emit your TLV field and that it does not match the one
checked by haproxy using hash_crc32c().

Thus you can freely continue to develop support for emitting the CRC32c
TLV header on your side without having to worry about my fix to propagate
through distro channels as it must work with any version supporting it
(unless there's a different bug in it but that's then a different story).

Thanks anyway for catching this ugly bug which I'm currently addressing!

Willy