[opensuse] Sandy - Postfix - Howto stop rejected mail from being sent to backup server?
List - Sandy: In my postfix setup, rbpllc.com is the primary mail host and 3111skyline.com is configured as a backup to it (same way we set it up a couple of years ago). The issue I am having is that all of the spam that is rejected by rbpllc.com's smtpd_recipient_restrictions is then sent to the backup 3111skyline.com where it is rejected under the same rules. Is there any way to stop the blocked mail from being sent to the backup host or is this just the natural consequence on the backup server scheme? (undeliverable at MX priority 10, the automatically sent to MX priority 20) Thanks for any help you can give! -- David C. Rankin, J.D.,P.E. | openSoftware und SystemEntwicklung Rankin Law Firm, PLLC | Countdown for openSuSE 11.1 www.rankinlawfirm.com | http://counter.opensuse.org/11.1/small -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday, 2008-12-05 at 21:23 -0600, David C. Rankin wrote:
The issue I am having is that all of the spam that is rejected by rbpllc.com's smtpd_recipient_restrictions is then sent to the backup 3111skyline.com where it is rejected under the same rules.
Is there any way to stop the blocked mail from being sent to the backup host or is this just the natural consequence on the backup server scheme? (undeliverable at MX priority 10, the automatically sent to MX priority 20)
I believe that is normal. Normal "good" mail would go to the backup server anyway, if the main server is down or something. Bad mail do so for double reasons: one, the same reason, two, "they" think that the backup server's security may be not so tight. So they try... nothing inherently bad in that, except that they are the bad guys. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkk59ssACgkQtTMYHG2NR9W3YwCfSz575HIiMiR1eWGOT2GjmU6o CmUAn23sGTINExh41AwA2CEQT12BDzIK =LdWX -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
You need to sent this question to the postfix mailing list they would
be better at answering this as it more about postfix and not opensuse.
On 12/5/08, David C. Rankin
List - Sandy:
In my postfix setup, rbpllc.com is the primary mail host and 3111skyline.com is configured as a backup to it (same way we set it up a couple of years ago).
The issue I am having is that all of the spam that is rejected by rbpllc.com's smtpd_recipient_restrictions is then sent to the backup 3111skyline.com where it is rejected under the same rules.
Is there any way to stop the blocked mail from being sent to the backup host or is this just the natural consequence on the backup server scheme? (undeliverable at MX priority 10, the automatically sent to MX priority 20)
Thanks for any help you can give!
-- David C. Rankin, J.D.,P.E. | openSoftware und SystemEntwicklung Rankin Law Firm, PLLC | Countdown for openSuSE 11.1 www.rankinlawfirm.com | http://counter.opensuse.org/11.1/small -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-- Sent from my mobile device ---------------------------------------- When a place gets crowded enough to require ID's, social collapse is not far away. It is time to go elsewhere. The best thing about space travel is that it made it possible to go elsewhere. -- Robert Heinlein -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
David C. Rankin wrote:
Is there any way to stop the blocked mail from being sent to the backup host or is this just the natural consequence on the backup server scheme? (undeliverable at MX priority 10, the automatically sent to MX priority 20)
It works as designed and intended. If an MX does not receive the mail, the next MX'es are tried in increasing order of weight. /Per -- /Per Jessen, Zürich -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Per Jessen wrote:
David C. Rankin wrote:
Is there any way to stop the blocked mail from being sent to the backup host or is this just the natural consequence on the backup server scheme? (undeliverable at MX priority 10, the automatically sent to MX priority 20)
It works as designed and intended. If an MX does not receive the mail, the next MX'es are tried in increasing order of weight.
/Per
Thanks Carlos, Chuck and Per! I've been on a witch hunt against script kiddies and spammers lately. The ssh on a high port was magic at stopping the kiddies cold, looking at the mail issue, it makes sense that the backup would simply have to deal with the mail that is rejected from the primary, but I thought I would just check to make sure no one had a silver-bullet in their bag of tricks. Thanks again. -- David C. Rankin, J.D.,P.E. | openSoftware und SystemEntwicklung Rankin Law Firm, PLLC | Countdown for openSuSE 11.1 www.rankinlawfirm.com | http://counter.opensuse.org/11.1/small -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
* David C. Rankin
Is there any way to stop the blocked mail from being sent to the backup host or is this just the natural consequence on the backup server scheme? (undeliverable at MX priority 10, the automatically sent to MX priority 20)
It works as designed and intended. If an MX does not receive the mail, the next MX'es are tried in increasing order of weight.
Thanks Carlos, Chuck and Per!
I've been on a witch hunt against script kiddies and spammers lately. The ssh on a high port was magic at stopping the kiddies cold, looking at the mail issue, it makes sense that the backup would simply have to deal with the mail that is rejected from the primary, but I thought I would just check to make sure no one had a silver-bullet in their bag of tricks.
You actually should deal with this is as soon as possible, since it's backscattering. Postfix has a README: http://www.postfix.org/BACKSCATTER_README.html -- Mads Martin Joergensen, http://mmj.dk "Why make things difficult, when it is possible to make them cryptic and totally illogical, with just a little bit more effort?" -- A. P. J. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday, 2008-12-06 at 20:05 +0100, Mads Martin Joergensen wrote: ...
You actually should deal with this is as soon as possible, since it's backscattering.
Huh? Why? Simply rejecting email on the server is not backscattering. A server has the right not to accept email it doesn't want or that is not deliverable, as long as it gives a reason. If the mail was sent with a faked from address and it bounces to that address, it was the responsibility of the server sending the email not to accept that mail for sending (relay), not of the receiving server. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkk64ukACgkQtTMYHG2NR9XbrwCcCONplepHEZpLDIBd/SvV1SJS EusAnRIaAYRw9plGOtrohl/2JPbUfRpM =Wnaw -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Carlos E. R. wrote:
On Saturday, 2008-12-06 at 20:05 +0100, Mads Martin Joergensen wrote:
...
You actually should deal with this is as soon as possible, since it's backscattering.
Huh? Why?
Simply rejecting email on the server is not backscattering. A server has the right not to accept email it doesn't want or that is not deliverable, as long as it gives a reason.
Reject is one thing, bounce is quite another.
If the mail was sent with a faked from address and it bounces to that address, it was the responsibility of the server sending the email not to accept that mail for sending (relay), not of the receiving server.
Please rethink the above paragraph Carlos. Its like you're ok with Joe jobs. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday, 2008-12-06 at 16:47 -0800, John Andersen wrote:
Carlos E. R. wrote:
On Saturday, 2008-12-06 at 20:05 +0100, Mads Martin Joergensen wrote:
...
You actually should deal with this is as soon as possible, since it's backscattering.
Huh? Why?
Simply rejecting email on the server is not backscattering. A server has the right not to accept email it doesn't want or that is not deliverable, as long as it gives a reason.
Reject is one thing, bounce is quite another.
David is rejecting.
If the mail was sent with a faked from address and it bounces to that address, it was the responsibility of the server sending the email not to accept that mail for sending (relay), not of the receiving server.
Please rethink the above paragraph Carlos. Its like you're ok with Joe jobs.
Could you please explain that? - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkk7IO4ACgkQtTMYHG2NR9VdqQCfS0XkfH33zR37KDl1l8kKIukJ mqkAnRiMKRzzna0Fh7XgSdTrrKXJFlZY =nNI3 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Carlos E. R. wrote:
If the mail was sent with a faked from address and it bounces to that address, it was the responsibility of the server sending the email not to accept that mail for sending (relay), not of the receiving server.
Please rethink the above paragraph Carlos. Its like you're ok with Joe jobs.
Explain a Joe Job? http://en.wikipedia.org/wiki/Joe_job You simply can't assume that the sending server is behaving properly these days. Setting up your receiving server with the assumption that other servers play by the rules is a recipe for disaster. I'm not sure what you really meant by the paragraph quoted above, but if it is in support of bouncing rather than rejecting it can't be justified. Side issue: Rejecting is pretty limited in functionality with regard to spam or virus prevention. You essentially have to accept it and then reject after the body arrives, but by that time you've already paid the price. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday, 2008-12-06 at 17:17 -0800, John Andersen wrote:
Carlos E. R. wrote:
If the mail was sent with a faked from address and it bounces to that address, it was the responsibility of the server sending the email not to accept that mail for sending (relay), not of the receiving server.
Please rethink the above paragraph Carlos. Its like you're ok with Joe jobs.
Explain a Joe Job? http://en.wikipedia.org/wiki/Joe_job
Ah. ] Online, a joe job is a spam attack using spoofed sender data and aimed ] at tarnishing the reputation of the apparent sender and/or induce the ] recipients to take action against him (see also e-mail spoofing). For a ] related phenomenon that is not targeted directly at a particular ] victim, see backscatter of email spam. And what does the expression "be ok with" mean in that context?
You simply can't assume that the sending server is behaving properly these days. Setting up your receiving server with the assumption that other servers play by the rules is a recipe for disaster.
Their problem, not mine. I'll provide for their bad play when it affects me, but not when it affects them.
I'm not sure what you really meant by the paragraph quoted above, but if it is in support of bouncing rather than rejecting it can't be justified.
And pray, where did I recommend bouncing? I think you were too fast jumping at the wrong conclusions. Please reread ;-)
Side issue: Rejecting is pretty limited in functionality with regard to spam or virus prevention. You essentially have to accept it and then reject after the body arrives, but by that time you've already paid the price.
If I know that I don't want the email, before it completes the negotiation, I reject it. If I knew 100% sure that it is spam, I could silently discard it... but if there is a chance that it isn't, there could be damages. So... if servers are silently discarding, that would be the perfect excuse for businesses not replying to supports email, for instance. "We never got it". Weak excuse for incompetence of their personnel at answering letters. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkk7KngACgkQtTMYHG2NR9U58wCfclmfi5VlcQw3le2JY0d6Oob6 N6kAnRvWh4PbbEKlnXI1fJcA0bHGIoA7 =+JuT -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Carlos E. R. wrote:
On Saturday, 2008-12-06 at 16:47 -0800, John Andersen wrote:
Carlos E. R. wrote:
On Saturday, 2008-12-06 at 20:05 +0100, Mads Martin Joergensen wrote:
...
You actually should deal with this is as soon as possible, since it's backscattering.
Huh? Why?
Simply rejecting email on the server is not backscattering. A server has the right not to accept email it doesn't want or that is not deliverable, as long as it gives a reason.
Reject is one thing, bounce is quite another.
David is rejecting.
If the mail was sent with a faked from address and it bounces to that address, it was the responsibility of the server sending the email not to accept that mail for sending (relay), not of the receiving server.
Please rethink the above paragraph Carlos. Its like you're ok with Joe jobs.
Could you please explain that?
-- Cheers, Carlos E. R.
Yes, Carlos is right,
I may have misspoke if I used the word bounced, what I'm doing is the standard
rejections based on smtpd_recipient_restrictions:
#
# smtpd_recipient_restrictions
#
smtpd_recipient_restrictions = permit_mynetworks,
permit_sasl_authenticated,
check_client_access
hash:/etc/postfix/clients_relay_allowed,
reject_unauth_destination,
check_recipient_access
pcre:/etc/postfix/recipient_check.pcre,
reject_invalid_helo_hostname,
reject_non_fqdn_helo_hostname,
reject_rbl_client sbl-xbl.spamhaus.org,
reject_rbl_client list.dsbl.org
#
# tightening Postfix
#
unknown_client_reject_code = 550
unknown_local_recipient_reject_code = 550
smtpd_hard_error_limit = 3
smtp_connect_timeout = 60s
The server isn't creating backscatter, it is doing what a mail server is
supposed to do with the gobs on UCE, etc. that it gets bombarded with, it's
rejecting with the 5XX reject code saying go away and don't come back!
This is where my knowledge ran out and my confusion began. On my backup mail
host, I always see "blah blah ... danh@guillorylaw.com..." This is rejected
mail from my primary server to which guillorylaw.com resolves, appearing in the
logs of my backup mail server at 3111skyline. The purpose of my original post
was to see if there was a way to stop the rejected mail from the primary from
also needing to be rejected by the backup. If I understand the discussion thus
far, the answer is (1) no, you just have to reject it there two preferably with
the same configuration your primary rejected it with, and (2) it is _not_
backscatter, this is just the way it works. I have included the log entries
seen on my backup mail host below, in case I am still really confused and don't
understand what it is I'm looking at (always a possibility - I'll need 3-4 more
e-mails back and forth with Sandy in this thread before it really sinks in ;-):
Dec 6 18:30:02 nirvana postfix/smtpd[22782]: NOQUEUE: reject: RCPT from
unknown[118.42.55.214]: 554 5.7.1 Service unavailable; Client host
[118.42.55.214] blocked using sbl-xbl.spamhaus.org;
http://www.spamhaus.org/query/bl?ip=118.42.55.214;
from=
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday, 2008-12-06 at 19:49 -0600, David C. Rankin wrote:
Yes, Carlos is right,
I may have misspoke if I used the word bounced, what I'm doing is the standard rejections based on smtpd_recipient_restrictions:
...
The server isn't creating backscatter, it is doing what a mail server is supposed to do with the gobs on UCE, etc. that it gets bombarded with, it's rejecting with the 5XX reject code saying go away and don't come back!
Right. However, let me explain how I see things but in different words, because I may have confused things a bit. Assume: A B C spammer --> bonafide server --> Our server. misconfigured, destination server. allows relay or has another problem. - A sends to B. - B accepts the email for C (bad thing). It could be a perverted machine, a misconfigured one, whatever. - B sends to C. - C rejects the email (according to the rules). - B is left with an email it can not deliver, and according to the rules, it can not discard, either. It has to bounce! So, B creates backscatter, not us. It is their problem. It is they who are misconfigured, because they accepted to send the email to the destination; if they are the proper server for the sender address, they did not authenticate it. And if they did, this email should be dropped on an admin address, investigate who sent it, and sue him. Add whatever combination you can think of bad administration at B causing this. But we are not doing wrong, we reject email. Their fault for accepting wrong email. True, the sender address is faked and it damages an innocent. I have my share of suffering that situation myself. But the alternative of silently dropping, is also wrong - and I don't see any other way. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkk7OS8ACgkQtTMYHG2NR9UqfgCePez0RELcIzfp1NUYDsH0llM6 GysAnjgA/+YnNIe4MXx39w98yaurrEmy =klKi -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Carlos E. R. wrote:
- A sends to B. - B accepts the email for C (bad thing). It could be a perverted machine, a misconfigured one, whatever. - B sends to C. - C rejects the email (according to the rules). - B is left with an email it can not deliver, and according to the rules, it can not discard, either. It has to bounce!
So, B creates backscatter, not us. It is their problem. It is they who are misconfigured, because they accepted to send the email to the destination; if they are the proper server for the sender address, they did not authenticate it. And if they did, this email should be dropped on an admin address, investigate who sent it, and sue him.
The more probable case (given the number of spam bots out there) is to relace your first two steps with 1 sends to B pretending to be A B is a co-conspirator and forwards the the mail to C (open relay) ... ... carry on as before.
Add whatever combination you can think of bad administration at B causing this.
No, bad intent is causing it.
But we are not doing wrong, we reject email. Their fault for accepting wrong email. True, the sender address is faked and it damages an innocent.
And that damage is far worse than the original spam, because it can totally swamp the mail server of some un-suspecting JOE who's return address settings were hijacked. I have my share of suffering that situation myself.
But the alternative of silently dropping, is also wrong - and I don't see any other way.
Silently dropping is becoming the recommended norm these days. After all a properly addressed email will be processed, and anyone emailing anything of importance can request a return receipt. Generating DSNs DOUBLES the spam problem. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday, 2008-12-06 at 19:11 -0800, John Andersen wrote:
Carlos E. R. wrote:
- A sends to B. - B accepts the email for C (bad thing). It could be a perverted machine, a misconfigured one, whatever. - B sends to C. - C rejects the email (according to the rules). - B is left with an email it can not deliver, and according to the rules, it can not discard, either. It has to bounce!
So, B creates backscatter, not us. It is their problem. It is they who are misconfigured, because they accepted to send the email to the destination; if they are the proper server for the sender address, they did not authenticate it. And if they did, this email should be dropped on an admin address, investigate who sent it, and sue him.
The more probable case (given the number of spam bots out there) is to relace your first two steps with 1 sends to B pretending to be A
In which case B should have authenticated A with login/pass or network. It is their fault.
B is a co-conspirator and forwards the the mail to C (open relay)
Again, B is at fault.
... ... carry on as before.
Add whatever combination you can think of bad administration at B causing this.
No, bad intent is causing it.
Bad intent is making use of bad administration of B.
But we are not doing wrong, we reject email. Their fault for accepting wrong email. True, the sender address is faked and it damages an innocent.
And that damage is far worse than the original spam, because it can totally swamp the mail server of some un-suspecting JOE who's return address settings were hijacked.
Maybe, but not our fault :-( We could instead find fault with the authorities that do not send to jail the perpetrators.
I have my share of suffering that situation myself.
But the alternative of silently dropping, is also wrong - and I don't see any other way.
Silently dropping is becoming the recommended norm these days. After all a properly addressed email will be processed, and anyone emailing anything of importance can request a return receipt. Generating DSNs DOUBLES the spam problem.
No, I don't think I can agree with silently dropping. Only the recipient of email can do that, not the server. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkk7SYAACgkQtTMYHG2NR9WTIACfdxryPrscenAswK1nVptW30Bl FroAnRkoAekcVGUjWoycrG9+FpqqXNHN =ijho -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
John Andersen wrote:
Silently dropping is becoming the recommended norm these days. After all a properly addressed email will be processed, and anyone emailing anything of importance can request a return receipt. Generating DSNs DOUBLES the spam problem.
John,
I'm still not sure how to accomplish the silent dropping you are talking
about. As set forth in my previous mail, I'm doing standard rejections on both
the primary and backup mail servers with:
#
# smtpd_recipient_restrictions
#
smtpd_recipient_restrictions = permit_mynetworks,
permit_sasl_authenticated,
check_client_access
hash:/etc/postfix/clients_relay_allowed,
reject_unauth_destination,
check_recipient_access
pcre:/etc/postfix/recipient_check.pcre,
reject_invalid_helo_hostname,
reject_non_fqdn_helo_hostname,
reject_rbl_client sbl-xbl.spamhaus.org,
reject_rbl_client list.dsbl.org
#
# tightening Postfix
#
unknown_client_reject_code = 550
unknown_local_recipient_reject_code = 550
smtpd_hard_error_limit = 3
smtp_connect_timeout = 60s
What else is it that I can do? Also, am I reading the logs on my backup right
in this context? The log entries on my backup concerning mail originally sent
to my primary that started this thread show rejected mail from my primary is
also attempting to be delivered to my backup. I wasn't sure exactly why or if I
could stop it, thus the original post. My reading of the logs from the backup said:
Dec 6 18:34:19 nirvana postfix/smtpd[26142]: connect from
gtn26.internetdsl.tpnet.pl[83.3.247.26]
Above a Polish site connects to begin the mail transaction(we don't have
clients in Poland)
Dec 6 18:34:21 nirvana postfix/smtpd[26142]: NOQUEUE: reject: RCPT from
gtn26.internetdsl.tpnet.pl[83.3.247.26]: 554 5.7.1 Service unavailable; Client
host [83.3.247.26] blocked using sbl-xbl.spamhaus.org;
http://www.spamhaus.org/query/bl?ip=83.3.247.26;
from=
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday, 2008-12-07 at 16:59 -0600, David C. Rankin wrote:
I'm still not sure how to accomplish the silent dropping you are talking about. As set forth in my previous mail, I'm doing standard rejections on both the primary and backup mail servers with:
It consists of accepting the email and storing on devnul. It is what postfix documents as the action "DISCARD". Be careful to only do it for spam and not for misconfigured servers, though... Also, notice that you are not saving your resources, because the email will have to be read completely into your system, using your bandwidth and cpu time. It might even cause you to receive more spam, as the spammers will think that you accept spam... - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkk8aysACgkQtTMYHG2NR9WFYwCfULtfNJwZ2j1/hojg3y64hljm PEwAnAql6JAAdkvvt5/rOKo4TwLz1rKm =x9PK -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Carlos E. R. wrote:
It consists of accepting the email and storing on devnul.
Also, notice that you are not saving your resources, because the email will have to be read completely into your system, using your bandwidth and cpu time.
Bandwidth and CPU time are way cheaper than MY time or staff time to wade thru the spam.
It might even cause you to receive more spam, as the spammers will think that you accept spam...
Spammers are sending from zombies, they have no idea and could care less if the spam goes thru or not. Until Spamassassin has a rational approach to early rejection you are pretty well stuck with accepting and then sending obvious high-scoring spam to dev/nul. The current approach of a dual-pass smtpd as is found in postfix-->Amavis-->postfix--(delivery) is just fundamentally difficult to manage where virus/spam scanning plugins are used. Sendmail style Milters have an advantage here. I wish posfix would make it easier to utilize early rejection. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday, 2008-12-07 at 16:51 -0800, John Andersen wrote:
Carlos E. R. wrote:
It consists of accepting the email and storing on devnul.
Also, notice that you are not saving your resources, because the email will have to be read completely into your system, using your bandwidth and cpu time.
Bandwidth and CPU time are way cheaper than MY time or staff time to wade thru the spam.
Please, please, do read the thread before you jump in, without learning first what we are talking about. We are comparing the action of "discard" with the action of "reject" at the mail server. In neither case is your time or your staff time going to be used reading discarded of rejected mail - because it is not there to be read. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkk8cdYACgkQtTMYHG2NR9UIuQCgipvODdjdNfMjJ70es34dYSoM b28Anj71BKK20qnj/D/E4gwoeMYUQ7tL =kWrm -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
John Andersen wrote:
Carlos E. R. wrote:
It consists of accepting the email and storing on devnul.
Also, notice that you are not saving your resources, because the email will have to be read completely into your system, using your bandwidth and cpu time.
Bandwidth and CPU time are way cheaper than MY time or staff time to wade thru the spam.
Certainly, but then why not reject it instead? Just like you would reject mail to an unknown recipient.
Until Spamassassin has a rational approach to early rejection you are pretty well stuck with accepting and then sending obvious high-scoring spam to dev/nul.
That's not a spamassassin issue, you can set it up with postfix. (even if it's a little cumbersome).
The current approach of a dual-pass smtpd as is found in postfix-->Amavis-->postfix--(delivery) is just fundamentally difficult to manage where virus/spam scanning plugins are used.
I don't use amavis, but I don't have any difficulties in running the dual-smtp setup. It works very well and is also easy to manage.
Sendmail style Milters have an advantage here. I wish posfix would make it easier to utilize early rejection.
Yes, that would be nice, I agree. -- /Per Jessen, Zürich -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
John Andersen wrote:
Carlos E. R. wrote:
It consists of accepting the email and storing on devnul.
Also, notice that you are not saving your resources, because the email will have to be read completely into your system, using your bandwidth and cpu time.
Bandwidth and CPU time are way cheaper than MY time or staff time to wade thru the spam.
Agreed.
It might even cause you to receive more spam, as the spammers will think that you accept spam...
Spammers are sending from zombies, they have no idea and could care less if the spam goes thru or not.
True again.
Until Spamassassin has a rational approach to early rejection you are pretty well stuck with accepting and then sending obvious high-scoring spam to dev/nul.
The current approach of a dual-pass smtpd as is found in postfix-->Amavis-->postfix--(delivery) is just fundamentally difficult to manage where virus/spam scanning plugins are used.
I am running Amavisd-new as a proxy-filter, so I can reject spam when it is recognised by Amavisd-new. Due to the resource consumption this is only advisable for low volume sites or sites with capable hardware.
Sendmail style Milters have an advantage here. I wish posfix would make it easier to utilize early rejection.
Most milters can be used with recent Postfix. The most used one is probably dkim-milter. -- Sandy List replies only please! Please address PMs to: news-reply2 (@) japantest (.) homelinux (.) com -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Sandy Drobic wrote:
I am running Amavisd-new as a proxy-filter, so I can reject spam when it is recognised by Amavisd-new. Due to the resource consumption this is only advisable for low volume sites or sites with capable hardware.
Even with very capable hardware, it usually takes too long. Most of the SA processing isn't CPU-bound - sometimes I wish it was, it would make it much easier to speed up processing. /Per -- /Per Jessen, Zürich -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Per Jessen wrote:
Sandy Drobic wrote:
I am running Amavisd-new as a proxy-filter, so I can reject spam when it is recognised by Amavisd-new. Due to the resource consumption this is only advisable for low volume sites or sites with capable hardware.
Even with very capable hardware, it usually takes too long. Most of the SA processing isn't CPU-bound - sometimes I wish it was, it would make it much easier to speed up processing.
No problem on my hardware. (^-^) It takes about 2 seconds to process a mail (from connect up to delivery to imap). I haven't timed it exactly to see which part of the SA tests take that long. But with 8 GB RAM, Quadcore 2.83 GHz and a BBU supported raid card with 5 disks I don't worry. If I've got the hardware I should use it. (^-^) -- Sandy List replies only please! Please address PMs to: news-reply2 (@) japantest (.) homelinux (.) com -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Sandy Drobic wrote:
Per Jessen wrote:
Sandy Drobic wrote:
I am running Amavisd-new as a proxy-filter, so I can reject spam when it is recognised by Amavisd-new. Due to the resource consumption this is only advisable for low volume sites or sites with capable hardware.
Even with very capable hardware, it usually takes too long. Most of the SA processing isn't CPU-bound - sometimes I wish it was, it would make it much easier to speed up processing.
No problem on my hardware. (^-^) It takes about 2 seconds to process a mail (from connect up to delivery to imap). I haven't timed it exactly to see which part of the SA tests take that long.
The ones that can take longer are the DNS lookups. Of course it depends on how much you process, but when a mailserver is doing 5-6 mails/second, it does slow down processing overall, regardlkess of the hardware. Most of my DNS lookups are even local.
But with 8 GB RAM, Quadcore 2.83 GHz and a BBU supported raid card with 5 disks I don't worry. If I've got the hardware I should use it. (^-^)
The funny thing is that even my test-system - a few ancient boxes of 400MHz PII with maybe 512M RAM each - can do about 1 mail/second. Starting SA/spamd takes a lot longer than on modern systems, but the processing isn't much slower than on my production systems which are running 2GHz. /Per -- /Per Jessen, Zürich -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday, 2008-12-08 at 10:17 +0100, Sandy Drobic wrote:
Even with very capable hardware, it usually takes too long. Most of the SA processing isn't CPU-bound - sometimes I wish it was, it would make it much easier to speed up processing.
No problem on my hardware. (^-^) It takes about 2 seconds to process a mail (from connect up to delivery to imap). I haven't timed it exactly to see which part of the SA tests take that long.
About eight seconds some times: grep spamd /var/log/mail.debug | grep "in.*seconds" | less -S spamd[678]: spamd: clean message (-5.5/5.0) for cer:1000 in 2.7 seconds, 4582 bytes. spamd[2650]: spamd: clean message (-3.6/5.0) for cer:1000 in 3.5 seconds, 5437 bytes. spamd[678]: spamd: clean message (-2.6/5.0) for cer:1000 in 2.7 seconds, 6435 bytes. spamd[2650]: spamd: clean message (-3.8/5.0) for cer:1000 in 1.8 seconds, 6897 bytes. spamd[678]: spamd: clean message (-4.7/5.0) for cer:1000 in 2.4 seconds, 5879 bytes. spamd[678]: spamd: clean message (-4.6/5.0) for cer:1000 in 2.6 seconds, 5001 bytes. spamd[2650]: spamd: clean message (-4.6/5.0) for cer:1000 in 3.5 seconds, 5032 bytes. spamd[5605]: spamd: clean message (-4.8/5.0) for cer:1000 in 2.4 seconds, 6354 bytes. spamd[678]: spamd: clean message (-4.9/5.0) for cer:1000 in 3.4 seconds, 13373 bytes. Those were fast. Ah, look: spamd[1071]: spamd: clean message (-5.2/5.0) for cer:1000 in 9.4 seconds, 5109 bytes. spamd[2046]: spamd: clean message (-2.6/5.0) for cer:1000 in 6.9 seconds, 7127 bytes. spamd[2046]: spamd: clean message (-97.5/5.0) for cer:1000 in 4.5 seconds, 25140 bytes. spamd[1071]: spamd: clean message (-97.5/5.0) for cer:1000 in 5.0 seconds, 26564 bytes. spamd[1071]: spamd: clean message (-97.5/5.0) for cer:1000 in 5.1 seconds, 20793 bytes.
But with 8 GB RAM, Quadcore 2.83 GHz and a BBU supported raid card with 5 disks I don't worry. If I've got the hardware I should use it. (^-^)
Bayes testing is slow, but the problem are the network tests. Sometimes I think it does tests that time out because the scripts configure a wrong server or something. It was a problem with opensuse 10.3 I could not identify. A solution is to increase the number of available SA children and how many simultaneous local connections postfix does (local in my case, that is). - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkk9FKgACgkQtTMYHG2NR9VIHwCfc2q6M9Oo9u43WZe+68QdVJ6j xosAniUUlltxCHXwhyFiDY/n19qG+Hf3 =w9q+ -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Hi! Am Montag 08 Dezember 2008 schrieb Carlos E. R.:
On Sunday, 2008-12-07 at 16:59 -0600, David C. Rankin wrote:
I'm still not sure how to accomplish the silent dropping you are talking about. As set forth in my previous mail, I'm doing standard rejections on both the primary and backup mail servers with:
It consists of accepting the email and storing on devnul. It is what postfix documents as the action "DISCARD". Be careful to only do it for spam and not for misconfigured servers, though...
From a legal point of view this is something really dangerous to do, at least in Germany. For the following, please keep in mind that IANAL. If you are providing a mailserver to others you MUST forward all recieved mails to it's declared recipients. The only thing you can do is mark it as spam so the recipient can /dev/null it automatically. But that must be done by the recipient. Imagine you /dev/null something important for you client ... . Rejected mail is not recieved, so you are out of trouble there. Actually even for a private mailserver you might have troubles when /dev/null- ing mails after having ack-ed their recieve, but that's more like claiming you never got the mail... Regards, Matthias -- Matthias Bach www.marix.org „Der einzige Weg, die Grenzen des Möglichen zu finden, ist ein klein wenig über diese hinaus in das Unmögliche vorzustoßen.“ - Arthur C. Clarke
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday, 2008-12-08 at 10:55 +0100, Matthias Bach wrote:
Hi!
Am Montag 08 Dezember 2008 schrieb Carlos E. R.:
On Sunday, 2008-12-07 at 16:59 -0600, David C. Rankin wrote:
I'm still not sure how to accomplish the silent dropping you are talking about. As set forth in my previous mail, I'm doing standard rejections on both the primary and backup mail servers with:
It consists of accepting the email and storing on devnul. It is what postfix documents as the action "DISCARD". Be careful to only do it for spam and not for misconfigured servers, though...
From a legal point of view this is something really dangerous to do, at least in Germany. For the following, please keep in mind that IANAL.
I agree absolutely. :-| I don't know if it is illegal in Spain, but I'm fully convinced it is not ethical on a server for other people.
If you are providing a mailserver to others you MUST forward all recieved mails to it's declared recipients. The only thing you can do is mark it as spam so the recipient can /dev/null it automatically. But that must be done by the recipient. Imagine you /dev/null something important for you client ... . Rejected mail is not recieved, so you are out of trouble there.
Absolutely.
Actually even for a private mailserver you might have troubles when /dev/null- ing mails after having ack-ed their recieve, but that's more like claiming you never got the mail...
Right. Many people claim that, anyway... :-( - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkk9FZgACgkQtTMYHG2NR9Wt3ACdHb+4uBMUZ4gRMKnqOcTqKuyI YW4Anj2WjKrZ9AG8SWheHOav0/0mDaY+ =uDYP -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Carlos E. R. wrote:
Right.
However, let me explain how I see things but in different words, because I may have confused things a bit.
Assume:
A B C spammer --> bonafide server --> Our server. misconfigured, destination server. allows relay or has another problem.
- A sends to B. - B accepts the email for C (bad thing). It could be a perverted machine, a misconfigured one, whatever. - B sends to C. - C rejects the email (according to the rules). - B is left with an email it can not deliver, and according to the rules, it can not discard, either. It has to bounce!
So, B creates backscatter, not us. It is their problem. It is they who are misconfigured, because they accepted to send the email to the destination; if they are the proper server for the sender address, they did not authenticate it. And if they did, this email should be dropped on an admin address, investigate who sent it, and sue him.
You got it. I'm 'C', and 'C' only in this picture. I would like to kill 'A', but don't give a damn about 'B', period... -- David C. Rankin, J.D.,P.E. | openSoftware und SystemEntwicklung Rankin Law Firm, PLLC | Countdown for openSuSE 11.1 www.rankinlawfirm.com | http://counter.opensuse.org/11.1/small -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday, 2008-12-07 at 00:06 -0600, David C. Rankin wrote:
You got it. I'm 'C', and 'C' only in this picture. I would like to kill 'A', but don't give a damn about 'B', period...
Yea. But there are two problems: 1: If B did their job right, A could not send that spam. Not indirectly at least: they would have to use their own servers and would be identified and blocked. 2: A is using 'from' addresses from innocent bystanders. Of course, if the authorities did their job right, 'A' would be in prison. Ok, that's excessive, fined a hefty amount, several times what they earned. Spam can only be stopped if the perpetrators get reprised. And this reminds me... I have heard of activities that seemed like attackers trying to learn the password used for smtp authentication. They were using a dictionary attack on a pop3 server: once they hit, they can use the smtp server, that often has the same password, to send "legitimate" email using the smtp server of an innocent. In this case, 'B' is correctly configured, AFAIK. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkk7sAsACgkQtTMYHG2NR9UzngCdHMORw52ULMt/GOF7SXvCZugb 9fQAn3LtLtA8nzT+e9JfS1D/A/bg6qEl =dp8X -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Per Jessen wrote:
David C. Rankin wrote:
Is there any way to stop the blocked mail from being sent to the backup host or is this just the natural consequence on the backup server scheme? (undeliverable at MX priority 10, the automatically sent to MX priority 20)
It works as designed and intended. If an MX does not receive the mail, the next MX'es are tried in increasing order of weight.
For normal mails this should only be the case if the first mx rejects the mails temporarily (error code 4xx). If your server rejects with a permanent error 5xx, then the sending server has to bounce the mail immediately. Greylisting for example must be implemented on both servers otherwise you will always get a temp reject on the first and then the mail will be accepted by the server without greylisting. What spammers do is their own secret. Sometimes the backup mx is hit almost exclusively, other times it isn't used at all. Generally, you should use the same mail policy on both mx so that a mail is rejected or accepted on both the same way. -- Sandy List replies only please! Please address PMs to: news-reply2 (@) japantest (.) homelinux (.) com -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Sandy Drobic wrote:
Per Jessen wrote:
David C. Rankin wrote:
Is there any way to stop the blocked mail from being sent to the backup host or is this just the natural consequence on the backup server scheme? (undeliverable at MX priority 10, the automatically sent to MX priority 20) It works as designed and intended. If an MX does not receive the mail, the next MX'es are tried in increasing order of weight.
For normal mails this should only be the case if the first mx rejects the mails temporarily (error code 4xx). If your server rejects with a permanent error 5xx, then the sending server has to bounce the mail immediately.
Greylisting for example must be implemented on both servers otherwise you will always get a temp reject on the first and then the mail will be accepted by the server without greylisting.
What spammers do is their own secret. Sometimes the backup mx is hit almost exclusively, other times it isn't used at all.
Generally, you should use the same mail policy on both mx so that a mail is rejected or accepted on both the same way.
Got it, that's how they're set up :-) -- David C. Rankin, J.D.,P.E. | openSoftware und SystemEntwicklung Rankin Law Firm, PLLC | Countdown for openSuSE 11.1 www.rankinlawfirm.com | http://counter.opensuse.org/11.1/small -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
participants (8)
-
Carlos E. R. -
Chuck Payne -
David C. Rankin -
John Andersen -
Mads Martin Joergensen -
Matthias Bach -
Per Jessen -
Sandy Drobic