[pfx] sendmail bounce messages

[Víctor Rubiella Monfort via Postfix-users]

Hi,

I want to prevent that sendmail milter rejections generates bounces 
messages. Reading sendmail documentation I see "-N" option:



echo "HELLO" | sendmail -N 'never' t...@test.es; echo $?

0

Jun  8 13:51:30 server.test postfix/cleanup[597560]: 077616620F: 
milter-reject: END-OF-MESSAGE from localhost[127.0.0.1]: 5.7.1 Rejected 
for policy reason; from= to=
Jun  8 13:51:30 server.test postfix/cleanup[597560]: 077616620F: 
to=, relay=none, delay=0.1, delays=0.1/0/0/0, dsn=5.7.1, 
status=bounced (Rejected for policy reason)



non-delivery notification seems not executed (no logs related). But logs 
shows as "status=bounced". This  generate confusions on post-log-anilisis.

I can prenvent this "status=bounced" on logs (status=rejected)?

Thanks!

___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: sendmail bounce messages

[Benny Pedersen via Postfix-users]

Víctor Rubiella Monfort via Postfix-users skrev den 2023-06-08 14:06:


echo "HELLO" | sendmail -N 'never' t...@test.es; echo $?


-N parameter only controls DSN, it does not do REJECT or BOUNCES

sendmail -f t...@test.es -bv t...@test.es -N never

more funny results

hopefully test.es is your domain

___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: sendmail bounce messages

[Wietse Venema via Postfix-users]

Victor Rubiella Monfort via Postfix-users:
> Hi,
> 
> I want to prevent that sendmail milter rejections generates bounces 
> messages. Reading sendmail documentation I see "-N" option:
> 
> echo "HELLO" | sendmail -N 'never' t...@test.es; echo $?
> 
> 0
> 
> Jun  8 13:51:30 server.test postfix/cleanup[597560]: 077616620F: 
> milter-reject: END-OF-MESSAGE from localhost[127.0.0.1]: 5.7.1 Rejected 
> for policy reason; from= to=
> Jun  8 13:51:30 server.test postfix/cleanup[597560]: 077616620F: 
> to=, relay=none, delay=0.1, delays=0.1/0/0/0, dsn=5.7.1, 
> status=bounced (Rejected for policy reason)
> 
> non-delivery notification seems not executed (no logs related). But logs 
> shows as "status=bounced". This  generate confusions on post-log-anilisis.
> I can prenvent this "status=bounced" on logs (status=rejected)?

This is not configurable. Perhaps your log analyzer could look for
messages that do not have an

: sender non-delivery notification: 

record. Those messages were not returned to the sender.

Wietse
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: sendmail bounce messages

[Wietse Venema via Postfix-users]

Wietse Venema via Postfix-users:
> Victor Rubiella Monfort via Postfix-users:
> > Hi,
> > 
> > I want to prevent that sendmail milter rejections generates bounces 
> > messages. Reading sendmail documentation I see "-N" option:
> > 
> > echo "HELLO" | sendmail -N 'never' t...@test.es; echo $?
> > 
> > 0
> > 
> > Jun  8 13:51:30 server.test postfix/cleanup[597560]: 077616620F: 
> > milter-reject: END-OF-MESSAGE from localhost[127.0.0.1]: 5.7.1 Rejected 
> > for policy reason; from= to=
> > Jun  8 13:51:30 server.test postfix/cleanup[597560]: 077616620F: 
> > to=, relay=none, delay=0.1, delays=0.1/0/0/0, dsn=5.7.1, 
> > status=bounced (Rejected for policy reason)
> > 
> > non-delivery notification seems not executed (no logs related). But logs 
> > shows as "status=bounced". This  generate confusions on post-log-anilisis.
> > I can prenvent this "status=bounced" on logs (status=rejected)?
> 
> This is not configurable. Perhaps your log analyzer could look for
> messages that do not have an
> 
> : sender non-delivery notification: 
> 
> record. Those messages were not returned to the sender.

Note that "sendmail -N" (and NOTIFY=NONE in RCPT TO comands) disable
sender notifications only, not postmaster notifications. Those are
configured with main.cf:notify_classes, and produce similar logging:

: postmaster non-delivery notification: 

When Postfix logs the status= value, it logs 'bounced' for compatibility
with logfile analyzers that were written when Postfix had no support
to disable sender non-delivery notifications.

Postfix 'status=' logging was inspred by RFC 3461, which uses
'failed' in non-delivery status notifications. I suppose that here
there could be a parameter setting to log 'failed' instead of
'bounced'. I would not log the REASON in the status= field; the
reason is logged in the text portion in the logfile record.

Wietse
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Fallback server for a migration

[Jérôme BECOT via Postfix-users]

If I get it, the virtual alias change to another domain then the 
smtp_generic_maps change back to the original domain ? It works fine.


I played with it and I'd like something generic because we don't have 
knowledge of all remaining adresses on the old mail.


I can set the smtp_generic like this:

@oldmx.abc.com @abc.com

But I can't do the same for the virtual alias (it changes email in all 
my local users to oldmx.abc.com and sends directly to the old server). 
Is there a solution to map any unknown user without providing emails in 
virtual aliases ?


Thank you

Le 07/06/2023 à 17:00, Wietse Venema via Postfix-users a écrit :

J?r?me BECOT via Postfix-users:

Hello,

I know that this may have been asked a few times, but I need some help:

I manage a server for the domain abc.org. The mx points to my server and
it is configured to:

- lookup virtual mailboxes and virtual aliases from LDAP
- send mails to dovecot

It works, but I'd like to handle recipients that does not exist in LDAP
(nor in Dovecot) and forward them to an older server, that used to own
the domain:

j...@abc.com  > exists in LDAP > delivered to Dovecot
jdaniel > does not exists in LDAP > forwarded to oldmx.abc.com

I have unsuccessfully tried to:

- add a hashed tranport map in virtual_transport_maps
- add it in transport_maps

That would fail with "User Unkonwn" errors.

You need a virtual alias:

/etc/postfix/main.cf:
 virtual_alias_maps = hash:/etc/postfix/virtual_alias

/etc/postfix/virtual_alias
 jdan...@abc.com  usern...@oldmx.abc.com

(or LDAP equivalent).

DO NOT add oldmx.abc.com to main.cf:virtual_alias_domains.

In the case that oldmx.abc.com rejects mail for
usern...@oldmx.abc.com, you also need:

/etc/postfix/main.cf:
 smtp_generic_maps = hash:/etc/postfix/smtp_generic

/etc/postfix/smtp_generic:
 usern...@oldmx.abc.com  usern...@abc.com

(or LDAP equivalent).

Wietse
___
Postfix-users mailing list --postfix-users@postfix.org
To unsubscribe send an email topostfix-users-le...@postfix.org

--
*Jérôme BECOT*___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Fallback server for a migration

[Wietse Venema via Postfix-users]

J?r?me BECOT via Postfix-users:
> If I get it, the virtual alias change to another domain then the 
> smtp_generic_maps change back to the original domain ? It works fine.
> 
> I played with it and I'd like something generic because we don't have 
> knowledge of all remaining adresses on the old mail.
> 
> I can set the smtp_generic like this:
> 
> @oldmx.abc.com @abc.com
> 
> But I can't do the same for the virtual alias (it changes email in all 
> my local users to oldmx.abc.com and sends directly to the old server). 
> Is there a solution to map any unknown user without providing emails in 
> virtual aliases ?

You will have to enumerate (all the the oldmx recipients), or (all
the abc recipients that should not be forwarded to oldmx).

1 - Enumerate virtual aliases for 'oldmx' users, as in my first response.

2 - All of the following: a) Enumerate all the abc users with 1:1
virtual aliases (u...@abc.com -> u...@abd.com),  b) use one wildcard
virtual alias (@abc.com -> @oldmx.abc.com) that forwards everything
else to oldmx.abc.com, c) use smtp_generic_maps as in my first
response, and d) use reject_unverified_recipient to avoid accepting
non-existent recipients.

Wietse

> Thank you
> 
> Le 07/06/2023 ? 17:00, Wietse Venema via Postfix-users a ?crit?:
> > J?r?me BECOT via Postfix-users:
> >> Hello,
> >>
> >> I know that this may have been asked a few times, but I need some help:
> >>
> >> I manage a server for the domain abc.org. The mx points to my server and
> >> it is configured to:
> >>
> >> - lookup virtual mailboxes and virtual aliases from LDAP
> >> - send mails to dovecot
> >>
> >> It works, but I'd like to handle recipients that does not exist in LDAP
> >> (nor in Dovecot) and forward them to an older server, that used to own
> >> the domain:
> >>
> >> j...@abc.com  > exists in LDAP > delivered to Dovecot
> >> jdaniel > does not exists in LDAP > forwarded to oldmx.abc.com
> >>
> >> I have unsuccessfully tried to:
> >>
> >> - add a hashed tranport map in virtual_transport_maps
> >> - add it in transport_maps
> > That would fail with "User Unkonwn" errors.
> >
> > You need a virtual alias:
> >
> > /etc/postfix/main.cf:
> >  virtual_alias_maps = hash:/etc/postfix/virtual_alias
> >
> > /etc/postfix/virtual_alias
> >  jdan...@abc.com  usern...@oldmx.abc.com
> >
> > (or LDAP equivalent).
> >
> > DO NOT add oldmx.abc.com to main.cf:virtual_alias_domains.
> >
> > In the case that oldmx.abc.com rejects mail for
> > usern...@oldmx.abc.com, you also need:
> >
> > /etc/postfix/main.cf:
> >  smtp_generic_maps = hash:/etc/postfix/smtp_generic
> >
> > /etc/postfix/smtp_generic:
> >  usern...@oldmx.abc.com  usern...@abc.com
> >
> > (or LDAP equivalent).
> >
> > Wietse
> > ___
> > Postfix-users mailing list --postfix-users@postfix.org
> > To unsubscribe send an email topostfix-users-le...@postfix.org
> -- 
> *J?r?me BECOT*
> ___
> Postfix-users mailing list -- postfix-users@postfix.org
> To unsubscribe send an email to postfix-users-le...@postfix.org
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: sendmail bounce messages

[Víctor Rubiella Monfort via Postfix-users]

As always, very grateful for your clarifications.

El 8/6/23 a las 18:12, Wietse Venema via Postfix-users escribió:

Wietse Venema via Postfix-users:

Victor Rubiella Monfort via Postfix-users:

Hi,

I want to prevent that sendmail milter rejections generates bounces
messages. Reading sendmail documentation I see "-N" option:

echo "HELLO" | sendmail -N 'never' t...@test.es; echo $?

0

Jun  8 13:51:30 server.test postfix/cleanup[597560]: 077616620F:
milter-reject: END-OF-MESSAGE from localhost[127.0.0.1]: 5.7.1 Rejected
for policy reason; from= to=
Jun  8 13:51:30 server.test postfix/cleanup[597560]: 077616620F:
to=, relay=none, delay=0.1, delays=0.1/0/0/0, dsn=5.7.1,
status=bounced (Rejected for policy reason)

non-delivery notification seems not executed (no logs related). But logs
shows as "status=bounced". This  generate confusions on post-log-anilisis.
I can prenvent this "status=bounced" on logs (status=rejected)?

This is not configurable. Perhaps your log analyzer could look for
messages that do not have an

 : sender non-delivery notification: 

record. Those messages were not returned to the sender.

Note that "sendmail -N" (and NOTIFY=NONE in RCPT TO comands) disable
sender notifications only, not postmaster notifications. Those are
configured with main.cf:notify_classes, and produce similar logging:

 : postmaster non-delivery notification: 

When Postfix logs the status= value, it logs 'bounced' for compatibility
with logfile analyzers that were written when Postfix had no support
to disable sender non-delivery notifications.

Postfix 'status=' logging was inspred by RFC 3461, which uses
'failed' in non-delivery status notifications. I suppose that here
there could be a parameter setting to log 'failed' instead of
'bounced'. I would not log the REASON in the status= field; the
reason is logged in the text portion in the logfile record.

Wietse
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] No Postfix novice, but need novice-like advice (was Postfix or Dovecot cracked?!)

[Richard Troy via Postfix-users]

Hi All,

This is my first posting here, and maybe I should have found this WAY back 
in January, '23, if not LONG before. Surely background will help:


This 27 or so year old site now with Fedora / Postfix / Dovecot (with 
early adoption of all three) that I built was humming along just fine 
until a major disaster in January and I've not yet been able to fully 
recover because the Postfix / Dovecot pair has let the damned spammers in 
again and again and again and again!


OH, sure, I got it down to a trickle, but these few Russian sites always 
managed to get their spam through. I've never found out how they got in, 
but I'm sure they'd be back as soon as I reopen internet access on ports 
587 and / or 993.


I went through so much pain at trying to reconfigure, to no success (or 
incomplete success) that I've STRONGLY suspected that either Dovecot or 
Postfix got cracked - at least the modern version of January '23 on Fedora 
Server 37. (I haven't reopened the ports since the upgrade to 38.)


As soon as 38 became available, we upgraded. Current version(s) available 
upon request - and while the whole main.cf is HUGE and somewhat 
sensitive, bits of it are surely available, too.


In the disaster, we lost /var but not /etc, so I figured recovery would be easy 
and for nearly everything, it was. But while both Dovecot and Postfix came 
right back up with the old config files (and something of an effort to try 
and use the more modern, insofar as they're different), nothing I've tried 
so far has stopped the spammers from getting through, though as I say I 
haven't tried since the update to 38 - should I now? (No config has 
changed.)


Now, in these 5+ months I've tried so many things, I'm sure I've forgotten 
most of them and I don't know that a retrospective look is worth doing.


...I kept some notes that might be useful if anyone wants to see the evidence 
of the cracking, but in short, I kept a constant watch on the logs and when ANY 
relay happened that shouldn't, I'd instantly know it and shut things off 
entirely. However, that became untenable as I couldn't find the problem and had 
to just shut it off, pissing off users, etc, but I've had to do things like 
spend a month and a half traveling, and so forth and, well... Life goes on, as 
the saying goes.


---

Given all the work I did on Postfix to stop relaying from unauthorized 
parties, and how after a mountain of work the "open-mail-relaying" was 
only coming from a couple of spammers in Russia, it's my view they somehow 
cracked things, even though we changed 100% of ALL user passwords to VERY, 
and I mean completely impractical to crack values (30 chars plus). And so 
I want to blame Dovecot for letting through the relaying. They say no, 
it's Postfix!


Maybe someone on this list knows if it's possible that Dovecot being 
cracked can cause Postfix to become a spam relay but I'd like to sidestep 
that for at least the moment:


A new feature that would make a HUGE difference to sites like mine: Give 
me a white-list of the ONLY accounts (usernames) that can relay; NOTHING 
ELSE can relay. ... THAT would do it! But no! Neither in Postfix nor 
Dovecot is there such a thing! ...Such a thing CANNOT be that hard to 
implement and obviously useful to many; is there a good reason NOT to do 
this? Or am I wrong and it HAS been done?


Combine that with a greylist type function (similar to the postgrey 
package I have installed now) where the usual IP addresses for particular 
relay users were let through, and new ones delayed, THAT would be awesome, 
too! And this isn't even all that hard to do - I could do it if I didn't 
already have a thousand obligations in life!


And if someone tells me I'm wrong and points me at how to do these things, I'll 
fall out of my damned chair! And after picking myself up, I'll find a way to 
send that person some sort of gift. THIS WOULD HAVE SOLVED ALL MY PROBLEMS. And 
I'm sure MANY others could use this, too!


As a small digression on some of the above: I think I don't know enough 
about how Postfix's use of port 587 is properly secured - the "submission 
port". OK, STARTTLS we're told, but is it Postfix or Dovecot doing the 
authentication? Does Postfix EVER read a password file? I think it does 
not, and so I say it has to be Dovecot, but some clearing up of that would 
be nice... And, now that I think of it could this be a way to prove which 
is guilty of letting the spammers in?


---

I MUST get Dovecot's use of the ports 587 / 993 working again to allow my 
outside users to get email again, but HOW THE HELL DO I DO THIS and NOT 
let the spammers in?!


Thanks for any and all help,
Richard

___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: SPF questions

[Benny Pedersen via Postfix-users]

wesley--- via Postfix-users skrev den 2023-06-09 02:17:

Hello,

for this spf setting,

bar.org. 3600   IN TXT "v=spf1 -all"


no ip addresses were provided.
does it mean all IP are passed, or no IP can pass?


no ip will pass

essentially all mails is rejected from that domain if recipient enforce 
spf policy test


___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org