Title pretty much says it all, what I'd like is for sendmail to quietly drop any incoming email if the email has any local recipents that are unknown users. This is in support for an anti-spam effort.
And example would to assume that there's an user named "foo", if and email is received that has cc: or bcc: to both "foo", and "bar" (which doesn't not exist), I'm more than willing to assume the email is a spam and I'd like to drop it sight unseen. I DO NOT want to send an email undeliverable notice to the supposed sender since that's frequently forged.
Res <comp-mail-sendm...@ausics.net> wrote: >On Sun, 25 Nov 2007, John Cochran wrote:
>> Title pretty much says it all, what I'd like is for sendmail to quietly >> drop any incoming email if the email has any local recipents that are >> unknown users. This is in support for an anti-spam effort.
>wrong thing to do, it needs to state no user but see below....
>> And example would to assume that there's an user named "foo", if >> and email is received that has cc: or bcc: to both "foo", and "bar" (which >> doesn't not exist), I'm more than willing to assume the email is a spam >> and I'd like to drop it sight unseen. I DO NOT want to send an email >> undeliverable notice to the supposed sender since that's frequently >> forged.
>errrr thats not how sendmail works, well not unless your using somthing >10 years old, in which case you would have bigger problems than >backscatter issues :)
>Sendmail does not generate a new DSN message, it gives the result in the >senders initial connection.
>Sendmail also doesnt care whats in to/from/bcc fields, it uses envelope >header details.
Yes, sendmail uses the envelope. And the envelope has one or more recipents listed in it. What I'd like is that if there is a non-existent local recipent listed, then the entire email is to be dropped even if one or more listed recipents exist.
>> Yes, sendmail uses the envelope. And the envelope has one or more >> recipents listed in it. What I'd like is that if there is a >> non-existent local recipent listed, then the entire email is to be >> dropped even if one or more listed recipents exist.
> That is the most stupidist thing I've read in here to date!
> So the sender makes a typo, and you punish the existing users as well, > I hope to christ you are talking about your own private home single > user dsl/cable connection, and not a system where other people use it, > whether they pay you or not.
And some poor admin at the sending end will be trying to explain to their users why their friend did not get their email and it MUST be the poor admin's fault.
Res <r...@ausics.net> writes: > On Sun, 25 Nov 2007, John Cochran wrote:
>> Yes, sendmail uses the envelope. And the envelope has one or more >> recipents listed in it. What I'd like is that if there is a >> non-existent local recipent listed, then the entire email is to be >> dropped even if one or more listed recipents exist.
> That is the most stupidist thing I've read in here to date!
Does it mean you read so little? :-)
It is something I would encourage *but* it may be quite effective way to stop many spam messages *IF* done properly e.g. * reject at the final dot * and optionally reject every "RCPT TO:" after invalid "RCPT TO:" without providing "misleading" reason
> So the sender makes a typo, and you punish the existing users as well, > I hope to christ you are talking about your own private home single > user dsl/cable connection, and not a system where other people use it, > whether they pay you or not.
It should make ham senders "retry" after fixing "invalid data". In most (but not all) cases ham senders will retry.
As I wrote: I would not recommend it but it may make sense in some
In article <Pine.LNX.4.64.0711261410480.2...@ebfjryy.nhfvpf.arg> Res
<r...@ausics.net> writes: >On Sun, 25 Nov 2007, Andrzej Adam Filip wrote:
>> It should make ham senders "retry" after fixing "invalid data". >> In most (but not all) cases ham senders will retry.
>But you say reject at invalid point, therefor any compliant MTA will not >bother resending once they've been 5xx'd, unless you want to reject them >with 4xx, but I feel thats not what he wants to do, he wants 5xx.
An MTA obviously can't "fix invalid data", so I assume Andrzej is talking about the human sender (and you certainly have a point in that not all senders are human). But actually the OP doesn't want to do either 4xx or 5xx, he wants to *drop* the message (if you consider the Subject open to interpretation, his initial message said "quietly drop", which removes all doubt) - and this is of course plain crazy. His (main) problem is apparently that he doesn't even understand that there is an alternative other than "send an email undeliverable notice".
>> stop many spam messages *IF* done properly e.g. >> * reject at the final dot >> * and optionally reject every "RCPT TO:" after invalid "RCPT TO:" >> without providing "misleading" reason
>>> So the sender makes a typo, and you punish the existing users as well, >>> I hope to christ you are talking about your own private home single >>> user dsl/cable connection, and not a system where other people use it, >>> whether they pay you or not.
>> It should make ham senders "retry" after fixing "invalid data". >> In most (but not all) cases ham senders will retry.
> But you say reject at invalid point, therefor any compliant MTA will not > bother resending once they've been 5xx'd, unless you want to reject them > with 4xx, but I feel thats not what he wants to do, he wants 5xx.
I talk about retry by "human" sender (as Per has suggested already). Smart and professional automated senders has got "built in" procedures for dealing with delivery problems including notification of human operator for "not seen before" reactions.
> [...] > I also think it did this by deliberate design due to the fact that most of > the tickets sold to these things, which range from a small sporting event > to major music concerts around the country, would not be uncommon for > it alone to send out millions of emails a day, anything from an automated > event inquiry responses to ticket updates and confirmations and requests. > So if it connected to send a batch (of 100) and the first user was an > invalid address for whatever reason, theres 99 more people that would > never get their responses based on that method, and I'd be hard pressed > to believe its the only one written that way.
I talk *only* about 1) rejecting with 5?? code in SMTP session any message even with single invalid recipient in SMTP rely "to the final dot" 2) eventually dropping later messages in the same SMTP session with 4?? code 3) eventually setting short 15-30m "4?? ban" on messages from the "offending" IP
If implemented correctly and responsibly the it *MAY* be quite efficient method of stopping spam *WITH* possible side effects you described.
It is up to "local postmaster" to decide if the method would be "cost effective". The opinions *WILL* vary :-)
In article <Pine.LNX.4.64.0711252253580.13...@ebfjryy.nhfvpf.arg>,
Res <comp-mail-sendm...@ausics.net> wrote: >On Sun, 25 Nov 2007, John Cochran wrote:
>> Yes, sendmail uses the envelope. And the envelope has one or more recipents >> listed in it. What I'd like is that if there is a non-existent local >> recipent listed, then the entire email is to be dropped even if one or more >> listed recipents exist.
>That is the most stupidist thing I've read in here to date!
>So the sender makes a typo, and you punish the existing users as well, I >hope to christ you are talking about your own private home single user >dsl/cable connection, and not a system where other people use it, whether >they pay you or not.
The mail server is a private server with only about a half dozen users. None of which are using the same mailing list.
Also, said server is getting a LOT of email with randomly guessed userids from spammers. And almost all of the spammed email has forged sender identification. Which means that I have a huge outgoing queue of "No Such User" and frankly, I want it to stop.
I agree, that this would not be a good idea on a large email server, but for the small one I'm dealing with, it would work and would eliminate a large load that's being placed on a small box.
j...@smof.fiawol.org (John Cochran) writes: > [...] > Also, said server is getting a LOT of email with randomly guessed > userids from spammers. And almost all of the spammed email has forged > sender identification. Which means that I have a huge outgoing queue > of "No Such User" and frankly, I want it to stop.
*FIRST* try to make your sendmail reject messages to invalid users in reply to "RCPT TO:" in SMTP session before trying anything so draconian as you suggest.
Such reject are default sendmail behavior => Give us a hint why your sendmail does not do it. Two most typical explanations: * your sendmail is an "internal mail server" separated by "email gateway" from the Internet * your sendmail acts as email gateway * you sendmail uses non standard local mailer (e.g. cyrus IMAP with old fashioned sendmail integration)
> The mail server is a private server with only about a half dozen users. > None of which are using the same mailing list.
Sounds the size of my home system :-)
> Also, said server is getting a LOT of email with randomly guessed userids > from spammers. And almost all of the spammed email has forged sender > identification. Which means that I have a huge outgoing queue of "No Such User" > and frankly, I want it to stop.
Check the delivery address on the way in, as AAF suggests, and don't take mail you can't deliver. Problem solved.
And try milter-greylist. That kills most of the spam coming our way.
[That said, my main hassle at present is the backscatter from systems that've accepted undeliverable spam, and are trying to bounce it -- my way, because my domains have been forged as sender. I'm afraid I now mark all treat such systems as spam sources in their own right. Draconian, but effective. Is there ever a /legitimate/ reason to accept email then afterwards find you don't know the user???? Laziness in system design doesn't count :-) ]
-- Mike Scott (unet <at> scottsonline.org.uk) Harlow Essex England
> [That said, my main hassle at present is the backscatter from systems > that've accepted undeliverable spam, and are trying to bounce it -- my > way, because my domains have been forged as sender. I'm afraid I now > mark all treat such systems as spam sources in their own right. > Draconian, but effective. Is there ever a /legitimate/ reason to > accept email then afterwards find you don't know the user???? > Laziness in system design doesn't count :-) ]
milter-null can help with this (the backscatter not the laziness).
> . >> [That said, my main hassle at present is the backscatter from systems >> that've accepted undeliverable spam, and are trying to bounce it -- my >> way, because my domains have been forged as sender. I'm afraid I now >> mark all treat such systems as spam sources in their own right. >> Draconian, but effective. Is there ever a /legitimate/ reason to >> accept email then afterwards find you don't know the user???? >> Laziness in system design doesn't count :-) ]
> milter-null can help with this (the backscatter not the laziness).
> Andy
Interesting idea. Shame about the licence conditions though. About as bad as M$.
-- Mike Scott (unet <at> scottsonline.org.uk) Harlow Essex England
|
