Rejecting backscatter mail in postfix
Hi,
I'm receiving certain backscatter mail (ie, mail sent by postmasters,
consisting of rejecting a mail with possible virus to the claimed
originator, which in the case of virus, can be faked, and thus are
possibly innocent). In this case, the bounce I get includes the full viral
load, which is a nuisance - and no, amavis-new does not detect it.
The problem is the "from":
Return-Path: <>
From: Mail Delivery System
On Sat, 2004-11-27 at 16:03, Carlos E. R. wrote:
Perhaps the problem could be that postfix is not checking the sender address for existence :-?
That would be:
smtpd_sender_restrictions = hash:/etc/postfix/access,reject_unknown_sender_domain
But that would cause a dns check for every mail, I suppose. What about reject_non_fqdn_sender?
I believe it would but the side effect would be rejecting email from people using dyndns sites wouldn't it? I mean a reverse lookup would not show the registered domain the same as the dyn domain. -- Ken Schneider UNIX since 1989 SuSE since 1998 * Only reply to the list please*
The Saturday 2004-11-27 at 18:48 -0500, Ken Schneider wrote:
Perhaps the problem could be that postfix is not checking the sender address for existence :-?
That would be:
smtpd_sender_restrictions = hash:/etc/postfix/access,reject_unknown_sender_domain
But that would cause a dns check for every mail, I suppose. What about reject_non_fqdn_sender?
I believe it would but the side effect would be rejecting email from people using dyndns sites wouldn't it? I mean a reverse lookup would not show the registered domain the same as the dyn domain.
Eummm... good question. :-? I believe reject_unknown_sender_domain shouldn't do a reverse check, but a direct one. For example, if I send as "noname@doesnotexist.com", postfix should do a query, like the command "host doesnotexist.com". If it comes out as non existing, the domain was invented, not real. I think dyndns should work, because the name should resolve. The postfix doc says: | reject_unknown_sender_domain | Reject the request when the sender mail address has no DNS A or MX | record. The unknown_address_reject_code parameter specifies the | response code for rejected requests (default: 450). The response is | always 450 in case of a temporary DNS error. | It should work, but there would be a delay, I use a modem... and this list is high traffic. At least, I think it only checks the envelope from, and that one is suse.com. Also, I'm not sure what would happen if the dns server fails. Is 450 a temporary or a definitive error? Thus, I'm considering 'reject_non_fqdn_sender' instead - as a matter of fact, I have it enabled right now: I'm waiting for a "mixmail" mail to see if it gets rejected or not. | reject_non_fqdn_sender | Reject the request when the address in the client MAIL FROM command | is not in fully-qualified domain form. The non_fqdn_reject_code | specifies the response code to rejected requests (default: 504). -- Cheers, Carlos Robinson
* Carlos E. R.
I believe reject_unknown_sender_domain shouldn't do a reverse check, but a direct one. For example, if I send as "noname@doesnotexist.com", postfix should do a query, like the command "host doesnotexist.com". If it comes out as non existing, the domain was invented, not real. I think dyndns should work, because the name should resolve.
I have no-ip.org which is similar to dyndns and employe reject_unknown_sender_domain and do not *seem* to have any problem with any mail. I look at the logs every morning and see nothing amiss. I sometimes get 300-400 rejects for unknown_sender_domain and for "User unknown in local recipient table". It's just that much more that SpamAssassin does not have to filter/reject. I have also noticed that /etc/postfix/access does not seem to perform as expected, but header_checks *does*. postfix-2.2_20040616-1 -- Patrick Shanahan Registered Linux User #207535 http://wahoo.no-ip.org @ http://counter.li.org HOG # US1244711 Photo Album: http://wahoo.no-ip.org/photos
The Saturday 2004-11-27 at 20:23 -0500, Patrick Shanahan wrote:
* Carlos E. R.
[11-27-04 20:11]: I believe reject_unknown_sender_domain shouldn't do a reverse check, but a direct one. For example, if I send as "noname@doesnotexist.com", postfix should do a query, like the command "host doesnotexist.com". If it comes out as non existing, the domain was invented, not real. I think dyndns should work, because the name should resolve.
I have no-ip.org which is similar to dyndns and employe reject_unknown_sender_domain and do not *seem* to have any problem with any mail. I look at the logs every morning and see nothing amiss.
Yes, when suse's default MTA was sendmail, it came with the equivalent option enabled, and it worked. I wonder why they disabled it in postfix. My only worry is that it will slow my download, I use a modem and here we pay by the minute: local calls are not free as I think most of N.A. uses. That's why I'm trying with 'reject_non_fqdn_sender' first.
I sometimes get 300-400 rejects for unknown_sender_domain and for "User unknown in local recipient table".
It's just that much more that SpamAssassin does not have to filter/reject.
I'll have to consider it.
I have also noticed that /etc/postfix/access does not seem to perform as expected, but header_checks *does*.
The access check is enabled with: smtpd_sender_restrictions = hash:/etc/postfix/access And, according to postfix documentation: Sender address restrictions The smtpd_sender_restrictions parameter restricts what sender addresses this system accepts in MAIL FROM commands. I understand that means that it checks "access" against the envelope from, and not the internal from: that's why it doesn't work for me in the mixmail case. The problem with header_checks (I know it would work) is that it acts too late, when using fetchmail. The whole email gets downloaded and then fetchmail generates a bounce message. Mmm, I wonder now... oh, well, another day. -- Cheers, Carlos Robinson
The Sunday 2004-11-28 at 04:01 +0100, I. wrote:
The Saturday 2004-11-27 at 20:23 -0500, Patrick Shanahan wrote:
I have no-ip.org which is similar to dyndns and employe reject_unknown_sender_domain and do not *seem* to have any problem with any mail. I look at the logs every morning and see nothing amiss.
Yes, when suse's default MTA was sendmail, it came with the equivalent option enabled, and it worked. I wonder why they disabled it in postfix.
My only worry is that it will slow my download, I use a modem and here we pay by the minute: local calls are not free as I think most of N.A. uses.
That's why I'm trying with 'reject_non_fqdn_sender' first.
Neither works. :-/ Not "reject_non_fqdn_sender, nor "reject_unknown_sender_domain", nor /etc/postfix/access. The sender empty sender address, "<>" is not rejected :-( Furthermore, reject_unknown_sender_domain rejects emails with false domain, true, except that then fetchmail simply doesn't flush them from the server, but leaves them there; with the result that they are tried on the next cycle, and I finally have to remove them manually. The remedy is worse than the illness :-/ -- Cheers, Carlos Robinson
* Carlos E. R.
The Saturday 2004-11-27 at 20:23 -0500, Patrick Shanahan wrote:
I have no-ip.org which is similar to dyndns and employe reject_unknown_sender_domain and do not *seem* to have any problem with any mail. I look at the logs every morning and see nothing amiss. Neither works. :-/
Not "reject_non_fqdn_sender, nor "reject_unknown_sender_domain", nor /etc/postfix/access. The sender empty sender address, "<>" is not rejected :-(
Furthermore, reject_unknown_sender_domain rejects emails with false domain, true, except that then fetchmail simply doesn't flush them from the server, but leaves them there; with the result that they are tried on the next cycle, and I finally have to remove them manually.
The remedy is worse than the illness :-/
The difference being I an *only* talking about mail routed directly to my machine address, not that which is obtained from othe providers via fetchmail. I receive a *very* minimal percentage of spam on my machine that is actually addressed to my machine, wahoo. Most of the spam that I receive is obtained via fetchmail from arbornet, myrealbox, hotmail, fastmail and yahoo, and hotmail does a better job rejecting spam than yahoo. I get virtually no spam via swissinfo. *If* I had an alternate (backup) address for my own mx, I would dump *all* of the other providers, but except for my cable charges, I pay nothing for my email system. If I had to use tiscali as a provider, I believe that I would *only* use mail via another _free_ provider such as swissinfo, or somewhere I could get some a shell account and/or control provided for the mail system, ie: "reject_non_fqdh..." -- Patrick Shanahan Registered Linux User #207535 http://wahoo.no-ip.org @ http://counter.li.org HOG # US1244711 Photo Album: http://wahoo.no-ip.org/photos
The Wednesday 2004-12-01 at 14:50 -0500, Patrick Shanahan wrote:
Not "reject_non_fqdn_sender, nor "reject_unknown_sender_domain", nor /etc/postfix/access. The sender empty sender address, "<>" is not rejected :-(
Furthermore, reject_unknown_sender_domain rejects emails with false domain, true, except that then fetchmail simply doesn't flush them from the server, but leaves them there; with the result that they are tried on the next cycle, and I finally have to remove them manually.
The remedy is worse than the illness :-/
The difference being I an *only* talking about mail routed directly to my machine address, not that which is obtained from othe providers via fetchmail. I receive a *very* minimal percentage of spam on my machine that is actually addressed to my machine, wahoo. Most of the spam that I receive is obtained via fetchmail from arbornet, myrealbox, hotmail, fastmail and yahoo, and hotmail does a better job rejecting spam than yahoo. I get virtually no spam via swissinfo.
Mmm. That may be true, but fetchmail routes mail through postfix. My main problem is that I can not make postfix reject those mails which "Return-Path" is empty ("<>"). That is, when postfix sees this: SMTP> MAIL FROM: <> SIZE=33229 it should reject that empty "From", but it doesn't. I have been told that an empty "Return-Path" is legal, and that is quite a surprise for me.
*If* I had an alternate (backup) address for my own mx, I would dump *all* of the other providers, but except for my cable charges, I pay nothing for my email system.
I pay nothing for any mail account of mine. Things are different here, because local phone calls are paid by the minute, whereas you most probably don't. Tiscali is also a phone company, so they get paid with my phone usage of their internet connection. But that is not my problem today with postfix :-)
If I had to use tiscali as a provider, I believe that I would *only* use mail via another _free_ provider such as swissinfo, or somewhere I could get some a shell account and/or control provided for the mail system, ie: "reject_non_fqdh..."
None of the services I know give that kind of service here... -- Cheers, Carlos Robinson
The Thursday 2004-12-02 at 01:58 +0100, Carlos E. R. wrote:
Mmm.
That may be true, but fetchmail routes mail through postfix. My main problem is that I can not make postfix reject those mails which "Return-Path" is empty ("<>"). That is, when postfix sees this:
SMTP> MAIL FROM: <> SIZE=33229
it should reject that empty "From", but it doesn't. I have been told that an empty "Return-Path" is legal, and that is quite a surprise for me.
I was directed to "http://www.google.com/search?hl=en&lr=&q=reject+empty+Return-Path%3A". On a debian list this subject was commented months ago, and it seems that yes, empty envelope-from are correct. Also, of course, it is too late to change the smtp standard, even if some abuse it. Therefore, empty "envelope-from" can not be rejected with "smtpd_sender_restrictions" in main.cf. There is no other recourse but using header_check or spam filters. -- Cheers, Carlos Robinson
* Patrick Shanahan;
*If* I had an alternate (backup) address for my own mx, I would dump *all* of the other providers, but except for my cable charges, I pay nothing for my email system.
you consider using www.zoneedit.com which you can have DNS control of your domain ( % domains are free) and for, IIRC, 10 US$ a year you can have a back MX. They do have spam control they just tag the mail so it would be much better to discrad mail that comes from your backup MX ( or some other service that provides backup MX services) Your second alternative is to get a rootserver on a hosting company and set that machine to act as the backup MX since now you control the MC machine you can have better antispam protection. Third alternative is not to use backup MX at all, since clever MTA should have a resending que for the mail somewhere between 4 to 5 days. So mail should not be getting lost. Since the spammers almots always use the backup MX to deliver their junk no backup MX also means less junk :-) -- Togan Muftuoglu | Unofficial SuSE FAQ Maintainer | Please reply to the list; http://susefaq.sf.net | Please don't put me in TO/CC. Nisi defectum, haud refiecendum
* Togan Muftuoglu
Third alternative is not to use backup MX at all, since clever MTA should have a resending que for the mail somewhere between 4 to 5 days. So mail should not be getting lost. Since the spammers almots always use the backup MX to deliver their junk no backup MX also means less junk
This is my present condition, but I still get undeliverable mail notices from suse ezmlm when I have had my system off the air for 30 minutes or longer for some kind of maintenance. note: the 30 minute time figure is a guesstimation rather than an accurate observation. But there is no handy way to see if your system has *lost* mail due to downtime that I know of. -- Patrick Shanahan Registered Linux User #207535 http://wahoo.no-ip.org @ http://counter.li.org HOG # US1244711 Photo Album: http://wahoo.no-ip.org/photos
The Thursday 2004-12-02 at 09:37 +0100, Togan Muftuoglu wrote:
Third alternative is not to use backup MX at all, since clever MTA should have a resending que for the mail somewhere between 4 to 5 days. So mail should not be getting lost. Since the spammers almots always use the backup MX to deliver their junk no backup MX also means less junk :-)
Why is that, what's the difference? The email, bona-fide, should reach destination regardless of using the main or the backup MX, shouldn't it? I don't see why spammers prefer the backup MX... :-? -- Cheers, Carlos Robinson
On Thu, 2 Dec 2004, Carlos E. R. wrote:
The Thursday 2004-12-02 at 09:37 +0100, Togan Muftuoglu wrote:
Third alternative is not to use backup MX at all, since clever MTA should have a resending que for the mail somewhere between 4 to 5 days. So mail should not be getting lost. Since the spammers almots always use the backup MX to deliver their junk no backup MX also means less junk :-)
Why is that, what's the difference? The email, bona-fide, should reach destination regardless of using the main or the backup MX, shouldn't it?
I don't see why spammers prefer the backup MX... :-?
Usually the backup MX is not as secured as the primary MX. Spammers have
found that 80 % of what will not go through a primary MX will go through a
secondary MX. This was given at I believe the FCC summit in November.
--
Boyd Gerber
The Thursday 2004-12-02 at 13:26 -0700, Boyd Lynn Gerber wrote:
Why is that, what's the difference? The email, bona-fide, should reach destination regardless of using the main or the backup MX, shouldn't it?
I don't see why spammers prefer the backup MX... :-?
Usually the backup MX is not as secured as the primary MX. Spammers have found that 80 % of what will not go through a primary MX will go through a secondary MX. This was given at I believe the FCC summit in November.
Ahh....! But that is sloppy administration, to say the least... -- Cheers, Carlos Robinson
participants (5)
-
Boyd Lynn Gerber
-
Carlos E. R.
-
Ken Schneider
-
Patrick Shanahan
-
Togan Muftuoglu