Re: Bombarded With Spam
On 26.09.17 12:02, Kirk Bocek wrote: Thank you Benny and Wietse. Things are better now. However I have lots of log entries like: Sep 26 11:57:52 amber postfix/smtpd[11213]: NOQUEUE: reject: RCPT from unknown[10.0.2.1]: 554 5.7.1 : Sender address rejected: No Spam; from= r...@wysina.com.tw> to= proto=SMTP helo= Looks like sender address rejection. the error message seems to be custom, which means you should search for check_sender_access in your config file. if this still applies: https://marc.info/?l=postfix-users&m=150628487603535&w=2 then you have: check_sender_access hash:/etc/postfix/sender_access, which means the sender is listed in /etc/postfix/sender_access First off, at what stage is this rejection happening? Obviously, I want it to happen during HELO to keep the bandwidth down. you can't reject sender at HELO stage, because at that stage the sender is not known yet. Second, this server is sitting behind a firewall (10.0.2.1). Is there anyway to get the sending IP address instead of the firewall? configure your firewall to do destination NAT, so you see the real source. Hiding real source causes big problems to spam detection. -- 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. The 3 biggets disasters: Hiroshima 45, Tschernobyl 86, Windows 95
Backscatter questions
Hello, I recently configured Postfix 3.1.0 on a low-volume, Internet facing server. Mail operations are normal, but I had two questions regarding backscatter. 1. From what I understand, “backscatter” refers to e-mails such as non-delivery reports being sent back to the originator of a spam message. As the originator is often a forged address, the non-delivery reports is essentially junk data. Would this be a correct definition for the term ? 2. Is it possible to white-list the generation of non-delivery reports for some hosts and prevent generation for all others ? For instance, if a Gmail user attempts to e-mail me but specifies a non-existent address, I want the non-delivery report to go them (and any other senders from @gmail.com), but all other reports should be stopped from being sent. Thanks for your help, - J
Re: Backscatter questions
J Doe skrev den 2017-09-27 19:49: I recently configured Postfix 3.1.0 on a low-volume, Internet facing server. Mail operations are normal, but I had two questions regarding backscatter. ... 1. From what I understand, “backscatter” refers to e-mails such as non-delivery reports being sent back to the originator of a spam message. As the originator is often a forged address, the non-delivery reports is essentially junk data. Would this be a correct definition for the term ? non delivery is not correct, if you have a local sender that try to send email outside your own local domains it would create a bounce if it could not be delivered, this is not spam btw 2. Is it possible to white-list the generation of non-delivery reports for some hosts and prevent generation for all others ? For instance, if a Gmail user attempts to e-mail me but specifies a non-existent address, I want the non-delivery report to go them (and any other senders from @gmail.com), but all other reports should be stopped from being sent. keep away from whitelists, since there is nothing to whitelist, but make sure your postfix does not accept and later bounce same mail since that could be with forged sender addresses its always safe to reject all the best
Re: Backscatter questions
> On Sep 27, 2017, at 2:08 PM, Benny Pedersen wrote: > > J Doe skrev den 2017-09-27 19:49: > >> I recently configured Postfix 3.1.0 on a low-volume, Internet facing >> server. Mail operations are normal, but I had two questions regarding >> backscatter. > > ... > >> 1. From what I understand, “backscatter” refers to e-mails such as >> non-delivery reports being sent back to the originator of a spam >> message. As the originator is often a forged address, the >> non-delivery reports is essentially junk data. Would this be a >> correct definition for the term ? > > non delivery is not correct, if you have a local sender that try to send > email outside your own local domains it would create a bounce if it could not > be delivered, this is not spam btw > >> 2. Is it possible to white-list the generation of non-delivery reports >> for some hosts and prevent generation for all others ? For instance, >> if a Gmail user attempts to e-mail me but specifies a non-existent >> address, I want the non-delivery report to go them (and any other >> senders from @gmail.com), but all other reports should be stopped from >> being sent. > > keep away from whitelists, since there is nothing to whitelist, but make sure > your postfix does not accept and later bounce same mail since that could be > with forged sender addresses > > its always safe to reject > > all the best Hi Benny, Thank you for your reply. My current setup is for virtual domain hosting. I have a domain (say example.org), that I forward e-mail to Gmail. So if there was j...@example.org Postfix forwards to jons_em...@gmail.com. As a result, the only local users I have are the service accounts on the e-mail server itself. What happens is I will get a spam message for a user @example.org. If the user is non-existent, a non-delivery report gets generated by mail server and goes back to the sender of the spam . . . whose address is likely forged. That means the report is generating traffic to a possibly legitimate e-mail server. I do want legitimate non delivery reports to go to real people e-mailing recipients @example.org. Almost all of the legitimate e-mail coming through is from people using Gmail, Outlook and so forth which is why I thought whitelisting those domaines for non delivery reports would be useful, whereas other servers are most likely forged and should be silently dropped. Is there a way to achieve this or as you noted, are whitelists to be avoided ? If whitelists are to be avoided what is the best practice for handling this scenario ? Thanks, - J
Re: Backscatter questions
J Doe skrev den 2017-09-27 22:20: [snip] Is there a way to achieve this or as you noted, are whitelists to be avoided ? If whitelists are to be avoided what is the best practice for handling this scenario ? why not add example.org on google apps mx ? :=) if useers not wanting your mailserver anyway, why even think about imap then ? still serious ?, then setyp postfix client sasl auth to gmail pr user if not want all that problems drop forwards
RE: RESOLVED: RE: wrong From: and Return Path: address
> > On Sep 26, 2017, at 11:23 PM, Michael Fox wrote: > > > > BTW, the mail provider found that the default sendmail config and their > own > > customized config both rewrote the From: header when the From: address > was > > for a domain that had a CNAME record. They said this is a config option > in > > sendmail and they prefer to operate this way. Interesting that my other > > Postfix machines don't do this, nor do many other large email providers. > > This is an obsolete option in Sendmail that violates decades old SMTP > standards, CNAME canonicalization of recipient domains went away in > RFC 2821 and there are many email domains that are aliases where the > mailbox address is expected to remain unmangled by CNAME expansion of > the domain part. The operators of the sending system are stuck in the > distant past. Thanks Viktor. Yes, I see section 3.6 now explicitly allows "CNAME RRs whose targets can be resolved, in turn, to MX or A RRs", which was the case in my situation. Good to know that Postfix does it better! Michael
Re: RESOLVED: RE: wrong From: and Return Path: address
On Wed, Sep 27, 2017 at 07:00:39PM -0700, Michael Fox wrote: > > This is an obsolete option in Sendmail that violates decades old SMTP > > standards, CNAME canonicalization of recipient domains went away in > > RFC 2821 and there are many email domains that are aliases where the > > mailbox address is expected to remain unmangled by CNAME expansion of > > the domain part. The operators of the sending system are stuck in the > > distant past. > > Thanks Viktor. Yes, I see section 3.6 now explicitly allows "CNAME RRs > whose targets can be resolved, in turn, to MX or A RRs", which was the case > in my situation. > > Good to know that Postfix does it better! Even Sendmail does it better in default and recommended configurations, the users in question are deliberately choosing to continue no longer sound practices. -- Viktor.
