Re: Recipient validation - WAS: Re: Moderated posts?
On Thu, Oct 16, 2014 at 9:34 PM, Tanstaafl wrote: > On 10/16/2014 7:40 AM, Joel Rees wrote: >> On Thu, Oct 16, 2014 at 7:58 PM, Tanstaafl wrote: >>> > On 10/15/2014 8:37 PM, Jerry Stuckle wrote: >> Tanstaafl couldn't answer it, and you can't either, because it's not >> violating any. >>> > >>> > I did answer it, you just ignored it or don't understand it. >>> > >>> > Quote: >>> > >>> > "You do not have to violate an RFC to break SMTP." >>> > >>> > Here is a real world example: >>> > >>> > Improperly configured TCP filtering features on firewalls and routers >>> > don't violate any specific RFC, but they certainly can break SMTP (and >>> > other things too). >> Thus, we can understand that you are an idealist that would rather see >> your version of SMTP rules be followed by everyone than try to follow >> the RFC yourself. >> >> Where are your SMTP rules spelled out, by the way? > > Ok, I just went and looked it up, and lo and behold... > > RFC 2821 is the controlling RFC if I'm not mistaken... > > https://tools.ietf.org/html/rfc2821 > > In there you'll find this: > > " The second step in the procedure is the RCPT command. > > RCPT TO: [ SP ] > >The first or only argument to this command includes a forward-path >(normally a mailbox and domain, always surrounded by "<" and ">" >brackets) identifying one recipient. If accepted, the SMTP server >returns a 250 OK reply and stores the forward-path. If the recipient >is known not to be a deliverable address, the SMTP server returns a >550 reply, typically with a string such as "no such user - " and the >mailbox name (other circumstances and reply codes are possible). >This step of the procedure can be repeated any number of times." > > So, how do you 'interpret' the pertinent part: > > "If the recipient is known not to be a deliverable address, the SMTP > server returns a 550 reply, typically with a string such as "no such > user - " and the mailbox name (other circumstances and reply codes are > possible)." > > ? > > Sounds to me like a mandate to reject invalid recipients at the RCPT-TO > stage. Well, I'll tell you what. Before I try to engage with you on this, I'm going to do my part and re-read RFCs 5321, 5322, 4409, and BCP 14 and several others referred to therein, completely, and make sure I understand them. I strongly encourage you to do the same. -- Joel Rees Be careful when you see conspiracy. Look first in your own heart, and ask yourself if you are not your own worst enemy. Arm yourself with knowledge of yourself. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caar43ip5ymnc3zvqsvyqwo3bgabwseaf1djcxif_lmsqsou...@mail.gmail.com
Re: Recipient validation - WAS: Re: Moderated posts?
On 10/16/2014 at 06:37 AM, Tanstaafl wrote: > Please do not send to me directly, I am on the list. > > On 10/15/2014 3:15 PM, Jerry Stuckle wrote: > >> On 10/15/2014 12:40 PM, Tanstaafl wrote: >>> The status code is not *sent* anywhere - it is a response >>> directly to the connecting machine. > >> Then how does it get back to the sending server? Magic? > > Can you not read? The CONNECTING MACHINE - the one that was directly > talking to YOUR server - is responmsible for that part of the > transaction. Spambots DO NOT DO THIS. I think there's a miscommunication here. I think that what you are calling the "connecting machine" is the same thing as what he is calling the "sending server". In both cases, I believe what is being referred to is "the machine to which the 'status code' will be sent". And I believe he's trying to (implicitly and passive-aggressively) point out is that the "status code" itself A: is a message, however tiny, and B: is "sent" from your "receiving server" to the "sending server"/"connecting machine" - and that, thus, a message is sent back. There are so many terms in this which appear to be being defined differently by the two sides of the discussion, it's no surprise that there's been so little real communication here; it's almost more surprising that there's been as much as there has. >>> It is then the responsibility of that machine that was talking to >>> your server to pass the response code back to the originating >>> *server* (not the sender of the email - there is a difference). > >> I didn't say the sender of the email. > > Maybe not, but I have no desire to go back through this thread to > see whether you ever did or not. You are apparently incapable of > communicating with semantic precision, so this time I'm really done. I don't think he's incapable of it; I think he's trying to browbeat you into accepting his terminology, by intentionally refusing to explain his meaning rather than simply point out where you didn't match it, so that you have to "figure out" for yourself what that meaning is - probably because figuring something out for yourself tends to lead to a deeper and more personally acceptable understanding. Which is fine enough up to a point, but past that point becomes a form of bad argument, and IMO we are very much past that point. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Recipient validation - WAS: Re: Moderated posts?
On 10/16/2014 7:40 AM, Joel Rees wrote: > On Thu, Oct 16, 2014 at 7:58 PM, Tanstaafl wrote: >> > On 10/15/2014 8:37 PM, Jerry Stuckle wrote: >>> >> Tanstaafl couldn't answer it, and you can't either, because it's not >>> >> violating any. >> > >> > I did answer it, you just ignored it or don't understand it. >> > >> > Quote: >> > >> > "You do not have to violate an RFC to break SMTP." >> > >> > Here is a real world example: >> > >> > Improperly configured TCP filtering features on firewalls and routers >> > don't violate any specific RFC, but they certainly can break SMTP (and >> > other things too). > Thus, we can understand that you are an idealist that would rather see > your version of SMTP rules be followed by everyone than try to follow > the RFC yourself. > > Where are your SMTP rules spelled out, by the way? Ok, I just went and looked it up, and lo and behold... RFC 2821 is the controlling RFC if I'm not mistaken... https://tools.ietf.org/html/rfc2821 In there you'll find this: " The second step in the procedure is the RCPT command. RCPT TO: [ SP ] The first or only argument to this command includes a forward-path (normally a mailbox and domain, always surrounded by "<" and ">" brackets) identifying one recipient. If accepted, the SMTP server returns a 250 OK reply and stores the forward-path. If the recipient is known not to be a deliverable address, the SMTP server returns a 550 reply, typically with a string such as "no such user - " and the mailbox name (other circumstances and reply codes are possible). This step of the procedure can be repeated any number of times." So, how do you 'interpret' the pertinent part: "If the recipient is known not to be a deliverable address, the SMTP server returns a 550 reply, typically with a string such as "no such user - " and the mailbox name (other circumstances and reply codes are possible)." ? Sounds to me like a mandate to reject invalid recipients at the RCPT-TO stage. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/543fbb6b.4000...@libertytrek.org
Re: OT: Re: Recipient validation - WAS: Re: Moderated posts?
On 10/16/2014 7:31 AM, Chris Bannister wrote: > On Thu, Oct 16, 2014 at 06:50:01AM -0400, Tanstaafl wrote: >> Anyone who runs a mail server and doesn't monitor the postmaster address >> shouldn't be running a mail server. > Tell that to yahoo, they *don't seem* to have a postmaster address nor an > abuse address. :( Then they shouldn't be running a mail server... ;) And they are in violation of the RFC that mandates that these two addresses always be available and monitored. But I'm sure they couldn't care less... ;) -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/543fb99b.1080...@libertytrek.org
Re: OT: Re: Recipient validation - WAS: Re: Moderated posts?
On 16/10/14 22:31, Chris Bannister wrote: > On Thu, Oct 16, 2014 at 06:50:01AM -0400, Tanstaafl wrote: >> >> Anyone who runs a mail server and doesn't keep logs shouldn't be running >> a mail server. >> >> *And* the postmaster address monitored, >> >> Anyone who runs a mail server and doesn't monitor the postmaster address >> shouldn't be running a mail server. > > Tell that to yahoo, they *don't seem* to have a postmaster address nor an > abuse address. :( > ab...@yahoo-inc.com domainad...@yahoo-inc.com abuse-cen...@yahoo-inc.com mail-ab...@yahoo-inc.com domain.t...@yahoo-inc.com NOTE: I haven't tried them, but they're valid email addresses (don't ask). If you are having problems lately (last six months) it's likely that you haven't deployed SPF and DKIM - contentious issues for, um, the more conservative mail admin. I like SPF and DKIM - guess I'm not that conservative. Increasingly you'll find you'll need it - more of us, less conservative mail admin are deploying it and slowly switching to dumping mail that doesn't. Without SPF & DKIM it's usually trivial to spoof a sender, one day spammers might work that out. SMTP Error codes:- https://help.yahoo.com/kb/postmaster/smtp-error-codes-sln23996.html?impressions=true You'll find other related links on the same page. Kind regards -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/543fa87b.5060...@gmail.com
Re: Recipient validation - WAS: Re: Moderated posts?
Guys - Please take this off-list. Things have gone way, way past the point where this is of an interest or relevance to anyone else on this list. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141016121446.ga20...@chew.redmars.org
Re: Recipient validation - WAS: Re: Moderated posts?
On Thu, 16 Oct 2014 06:54:09 -0400 Tanstaafl wrote: Hello Tanstaafl, >On 10/15/2014 5:12 PM, Brad Rogers wrote: >> Send an email with a large attachment(1) and there are quite a few >> servers that will silently drop it. >Anyone who does that is breaking SMTP. If you don't want messages over Yes, that's the point. >certain size, REJECT them, but absolutely do not EVER accept then >silently delete them, that is just plain stupid. Oh I agree, wholeheartedly. As I said in my reply to Joe, I suspect it's part of a misguided anti-malware program. >> The worst of it is you can never know for certain if you're going to >> get "bitten" because routing can vary. >It isn't about routing problems, it is about properly configuring your >toolset. What I meant was that, since at any given time a route from A-B can vary due to, for example a server being down, you can't be sure which route the mail will take and therefore, which server(s) it'll pass through and what their reject/drop rules are. So, not routing per se, but unpredictable consequences of passing through certain servers. >> (1) 4Meg or so used to do the trick. Things might be different now s >Google accepts 25MB+, as does Outlook.com and most other freemailers >now. That is our limit here too. Things are much better than I hoped then. I'll keep that in mind for future use. Thanks. -- Regards _ / ) "The blindingly obvious is / _)radnever immediately apparent" I must be hallucinating, watching angels celebrating There Must Be An Angel (Playing With My Heart) - Eurythmics pgpXoM5d0tsJX.pgp Description: OpenPGP digital signature
Re: Recipient validation - WAS: Re: Moderated posts?
On Thu, Oct 16, 2014 at 7:58 PM, Tanstaafl wrote: > On 10/15/2014 8:37 PM, Jerry Stuckle wrote: >> Tanstaafl couldn't answer it, and you can't either, because it's not >> violating any. > > I did answer it, you just ignored it or don't understand it. > > Quote: > > "You do not have to violate an RFC to break SMTP." > > Here is a real world example: > > Improperly configured TCP filtering features on firewalls and routers > don't violate any specific RFC, but they certainly can break SMTP (and > other things too). Thus, we can understand that you are an idealist that would rather see your version of SMTP rules be followed by everyone than try to follow the RFC yourself. Where are your SMTP rules spelled out, by the way? -- Joel Rees Be careful when you see conspiracy. Look first in your own heart, and ask yourself if you are not your own worst enemy. Arm yourself with knowledge of yourself. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAAr43iMhgnbTZiDfiG=yyV8cC5O+=-pttkhdaxemzqub6x3...@mail.gmail.com
Re: OT: Re: Recipient validation - WAS: Re: Moderated posts?
On Thu, Oct 16, 2014 at 06:50:01AM -0400, Tanstaafl wrote: > > Anyone who runs a mail server and doesn't keep logs shouldn't be running > a mail server. > > *And* the postmaster address monitored, > > Anyone who runs a mail server and doesn't monitor the postmaster address > shouldn't be running a mail server. Tell that to yahoo, they *don't seem* to have a postmaster address nor an abuse address. :( -- "If you're not careful, the newspapers will have you hating the people who are being oppressed, and loving the people who are doing the oppressing." --- Malcolm X -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141016113134.GB9534@tal
Re: Recipient validation - WAS: Re: Moderated posts?
On 10/15/2014 8:37 PM, Jerry Stuckle wrote: > Tanstaafl couldn't answer it, and you can't either, because it's not > violating any. I did answer it, you just ignored it or don't understand it. Quote: "You do not have to violate an RFC to break SMTP." Here is a real world example: Improperly configured TCP filtering features on firewalls and routers don't violate any specific RFC, but they certainly can break SMTP (and other things too). -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/543fa4cd.8010...@libertytrek.org
Re: Recipient validation - WAS: Re: Moderated posts?
On 10/15/2014 5:12 PM, Brad Rogers wrote: > Send an email with a large attachment(1) and there are quite a few > servers that will silently drop it. Anyone who does that is breaking SMTP. If you don't want messages over a certain size, REJECT them, but absolutely do not EVER accept then silently delete them, that is just plain stupid. > The worst of it is you can never know for certain if you're going to > get "bitten" because routing can vary. It isn't about routing problems, it is about properly configuring your toolset. > (1) 4Meg or so used to do the trick. Things might be different now as > more and more messages contain massive amounts of HTML and imagery. Google accepts 25MB+, as does Outlook.com and most other freemailers now. That is our limit here too. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/543fa3d1.9030...@libertytrek.org
Re: OT: Re: Recipient validation - WAS: Re: Moderated posts?
On 10/15/2014 4:58 PM, Joe wrote: > It's worth some effort, at the moment it is the single most effective > anti-spam measure. If you outsource your mail, it's worth going to some > trouble to find a hosting company who will hold and accept updates for > a list of valid recipients. Or even easier, just get them to agree to let you perform recipient verification in realtime. > if it is spam, there's nobody to tell, and you don't want to send a > copy of the spam to the forged Reply-To: address. Of course not - which is why you REJECT it instead of ACCEPT+BOUNCE.. >> 3. once an email has been accepted for final delivery, every effort >> should be taken to deliver the message to the recipient, whether to >> their Inbox clean or tagged as spam (if a spam threshhold is met), >> or to a spam quarantine, > Which shouldn't be a problem if there's a valid recipient. Well, since everything I'm talking about is not accepting mail for invalid recipients, not sure why you felt the need to say that. > Yes, and a log kept. Anyone who runs a mail server and doesn't keep logs shouldn't be running a mail server. *And* the postmaster address monitored, Anyone who runs a mail server and doesn't monitor the postmaster address shouldn't be running a mail server. > and a request to know the disposition of a vanished email should be > answered, along with the reason. Especially if the request is > accompanied by one of your message IDs... Absolutely... > Of course. Already-accepted spam *must* be silently dropped. Absolutely NOT! It should be *delivered*, either tagged as spam to the Inbox, or to a quarantine, but it should be delivered. I only allow tagged delivery for more sophisticated users. Normal users have to check their quarantine. The only exception on my system is anything with a verified malicious payload, which is delivered to an admin mailbox, not to the intended recipient/victim. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/543fa2d9.1080...@libertytrek.org
Re: Recipient validation - WAS: Re: Moderated posts?
On 10/15/2014 4:44 PM, Joe wrote: > However, if the Reply-To: is forged, i.e. if it is spam, the > alternative is considerably less OK. Bouncing a spam message simply > delivers *the* *entire* *message* to an innocent third party, having > been laundered through your (presumably legitimate and respectable) mail > server. > > So it isn't OK, but there's no alternative to doing it. That's how you > have it both ways. Spam doesn't have to be deleted, it can be quarantined. That is the best way to handle spam once it has been accepted. I don't even delete the malicious stuff, although I don't deliver it to the recipient. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/543fa10c.6010...@libertytrek.org
Re: Recipient validation - WAS: Re: Moderated posts?
Please do not send to me directly, I am on the list. On 10/15/2014 3:15 PM, Jerry Stuckle wrote: > On 10/15/2014 12:40 PM, Tanstaafl wrote: >> Easy enough to prove. By all means, quote the actual text of me saying >> this was 'OK'... > You said: > > "However, once a message has been accepted - ie, *after* the DATA phase > is complete, it should never be bounced, it should be delivered - or, > worse, quarantined, or worst case, deleted (ie, if it is later found to > contain a malicious payload)." And nowhere do you see the word 'OK'. As I said, please do NOT put words in my mouth. > It is either OK to delete an email or it is not. You can't have it both > ways. If, as according to your other statements, it is not OK to delete > emails, then you are violating your own rules by deleting mails - for > ANY reason. If you are unable to see the difference between a rare, extreme worst case scenario of having discovered an email that you accepted for delivery contains a malicious payload, and deleting an email for no other reason than the recipient has a typo in it, then you have no business running a mail server. > Your reason is "i.e. if it is later found to contain a malicious > payload". My reason is "It is addressed to a non-existent user". > Either both are OK or neither is OK. So, you obviously have no business running a mail server. you keep saying that the RECEIVING server 'sends a message back to the originator' - unless maybe you simply have a hard time saying what you really mean, which always causes confusion. >> >>> it does send a message back to the originator - it may only be a >>> status code, but it is still a message. >> >> The status code is not *sent* anywhere - it is a response directly to >> the connecting machine. > Then how does it get back to the sending server? Magic? Can you not read? The CONNECTING MACHINE - the one that was directly talking to YOUR server - is responmsible for that part of the transaction. Spambots DO NOT DO THIS. >> It is then the responsibility of that machine that was talking to your >> server to pass the response code back to the originating *server* (not >> the sender of the email - there is a difference). > I didn't say the sender of the email. Maybe not, but I have no desire to go back through this thread to see whether you ever did or not. You are apparently incapable of communicating with semantic precision, so this time I'm really done. Respond if you like, I won't see it. > And you still can't quote an RFC which indicates what I am doing "breaks > SMTP". That's because there isn't one and I am NOT breaking SMTP. As I said, there is no rule that says that you have to violate an RFC to break SMTP. Accepting invalid recipients then silently deleting them breaks SMTP for the vast majority of internet email users. You are free to break it all you want... on your server. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/543f9ffc.6030...@libertytrek.org
Re: OT: Re: Recipient validation - WAS: Re: Moderated posts?
On 10/15/2014 3:13 PM, Miles Fidelman wrote: > Tanstaafl wrote: >> 1. email to invalid recipients should be rejected at the RCPT-TO stage, > Easier said then done - at least when a server does relaying, but > clearly ideal when possible. No, it is 100% easily done. For servers under your control, you just do it. If you don't know how and are unwilling or unable to learn how, then you have no business running a mail server. For servers not under your direct control, but for whom your server is the official relay for final delivery (which means you need the current list o valid recipients), you either require them to allow you to perform recipient verification, or to provide you with a constantly up to date list of valid recpients, or you don't act as their relay. > Generally agree with you in principle. And that's certainly the > standards-compliant policy. > > In practice I support a few dozen mailing lists - operational > necessity dictates dropping a lot of stuff silently. Lists are different, and definitely fall into the category of 'best effort, but no promises'... -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/543f9df8.3080...@libertytrek.org
Re: Recipient validation - WAS: Re: Moderated posts?
On Thu, 16 Oct 2014 09:23:02 +0100
Joe wrote:
Hello Joe,
{snipped explanations}
All very useful info, thanks; Cleared up a few things for me.
>I'm not for a moment doubting that it happens as you say, but there's
>no need for it in the case of a legitimate email, it is always possible
I suspect that it happens as part of a mis-guided (or ill-conceived)
anti-spam policy (any attachment that large *must* have a nasty payload,
etc, etc.) To be fair, I've not fallen foul of the problem for some
time. Having said that, there's been little need for me to send or
receive large files for some time.
These days, if I do need to transmit or receive large files, I upload
them to a file-space somewhere and ask the intended recipient to
download them, and ask them to do the same, so I can download. This has
the (minor) bonus that people's mailboxes don't get clogged, and they
can download at a time that's convenient to them, rather than when it's
handy for me to send it.
--
Regards _
/ ) "The blindingly obvious is
/ _)radnever immediately apparent"
I'm spending all my money and it's going up my nose
Teenage Depression - Eddie & The Hot Rods
pgpdhk939z72Z.pgp
Description: OpenPGP digital signature
Re: Recipient validation - WAS: Re: Moderated posts?
On Wed, 15 Oct 2014 22:12:41 +0100 Brad Rogers wrote: > On Wed, 15 Oct 2014 21:44:30 +0100 > Joe wrote: > > Hello Joe, > > >It is *not* OK to silently delete an already accepted email, it does > > Unfortunately, it happens; Send an email with a large attachment(1) > and there are quite a few servers that will silently drop it. The > worst of it is you can never know for certain if you're going to get > "bitten" because routing can vary. > > (1) 4Meg or so used to do the trick. Things might be different now as > more and more messages contain massive amounts of HTML and imagery. > Possibly so, but in every case somebody has messed up. Firstly an MTA trying to send a large file should query whether the receiving server is happy with that. There will be receive limits on email size directly, but also the recipient's mailbox may not have enough spare space, and policy may be to refuse the large email rather than quarantine it somewhere else. If the receiving server isn't happy, the transaction is aborted and the sender told. If the sending server sends more than the receiver is happy with, even if no protest was raised earlier, or no warning of the size was given, the receiver can simply not acknowledge receipt, or indeed just terminate the TCP session, and again the sending server notifies the email sender, possibly after a couple of re-tries if it has not been explicitly told that the message isn't welcome. If a large email is accepted, but only later it is found that it cannot be delivered by reason of some policy, then it's up to the receiving server to tell the recipient. I'm not for a moment doubting that it happens as you say, but there's no need for it in the case of a legitimate email, it is always possible either for the receiving server to fail to complete the SMTP transaction, or for recipient-end processing to inform the recipient of any post-acceptance delivery problems. Either the sender or the recipient *can* be told. -- Joe -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141016092302.67e8c...@jresid.jretrading.com
Re: Recipient validation - WAS: Re: Moderated posts?
On 10/15/2014 4:44 PM, Joe wrote:
> On Wed, 15 Oct 2014 15:15:24 -0400
> Jerry Stuckle wrote:
>
>
>>
>> It is either OK to delete an email or it is not. You can't have it
>> both ways.
>
> It is *not* OK to silently delete an already accepted email, it does
> indeed break SMTP as a reliable protocol ('reliable' as in: 'either we
> deliver it or we tell you we didn't').
>
> However, if the Reply-To: is forged, i.e. if it is spam, the
> alternative is considerably less OK. Bouncing a spam message simply
> delivers *the* *entire* *message* to an innocent third party, having
> been laundered through your (presumably legitimate and respectable) mail
> server.
>
> So it isn't OK, but there's no alternative to doing it. That's how you
> have it both ways.
>
OK, then the same question as I had for Tanstaafl - exactly WHICH RFC is
it in violation of?
Tanstaafl couldn't answer it, and you can't either, because it's not
violating any.
So, it's only your opinion.
Jerry
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/543f1347.2060...@attglobal.net
Re: Recipient validation - WAS: Re: Moderated posts?
On Wed, 15 Oct 2014 21:44:30 +0100 Joe wrote: Hello Joe, >It is *not* OK to silently delete an already accepted email, it does Unfortunately, it happens; Send an email with a large attachment(1) and there are quite a few servers that will silently drop it. The worst of it is you can never know for certain if you're going to get "bitten" because routing can vary. (1) 4Meg or so used to do the trick. Things might be different now as more and more messages contain massive amounts of HTML and imagery. -- Regards _ / ) "The blindingly obvious is / _)radnever immediately apparent" You destroyed my confidence, you broke my nerve Nervous Wreck - Radio Stars pgp_apVXIOFzl.pgp Description: OpenPGP digital signature
Re: OT: Re: Recipient validation - WAS: Re: Moderated posts?
On Wed, 15 Oct 2014 15:13:27 -0400 Miles Fidelman wrote: > Tanstaafl wrote: > > My position is that: > > > > 1. email to invalid recipients should be rejected at the RCPT-TO > > stage, > > Easier said then done - at least when a server does relaying, but > clearly ideal when possible. > It's worth some effort, at the moment it is the single most effective anti-spam measure. If you outsource your mail, it's worth going to some trouble to find a hosting company who will hold and accept updates for a list of valid recipients. > > > > 2. under *no* circumstances should mail to invalid recipients be > > accepted for delivery then silently deleted based solely on that one > > criteria, Not on that alone, no, it could be a typo, in which case the sender needs to be informed. But if it is spam, there's nobody to tell, and you don't want to send a copy of the spam to the forged Reply-To: address. > > > > and > > > > 3. once an email has been accepted for final delivery, every effort > > should be taken to deliver the message to the recipient, whether to > > their Inbox clean or tagged as spam (if a spam threshhold is met), > > or to a spam quarantine, Which shouldn't be a problem if there's a valid recipient. > > > > I allow for the very rare 'clear-and-present-danger' exceptional > > circumstance that, if an after-queue content scanner determines > > with a very high probability that something contains a malicious > > payload, an admin might want to not deliver it to the recipient. > > But, I would also argue that it should go into a quarantine that > > only the admin has access to, and never just silently deleted. > > Yes, and a log kept. *And* the postmaster address monitored, and a request to know the disposition of a vanished email should be answered, along with the reason. Especially if the request is accompanied by one of your message IDs... > > But, as Jerry says, that is just my opinion... Indeed. Within his domain, the email admin is king... > > > > Generally agree with you in principle. And that's certainly the > standards-compliant policy. > > In practice I support a few dozen mailing lists - operational > necessity dictates dropping a lot of stuff silently. Of course. Already-accepted spam *must* be silently dropped. -- Joe -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141015215812.021c2...@jresid.jretrading.com
Re: Recipient validation - WAS: Re: Moderated posts?
On Wed, 15 Oct 2014 15:15:24 -0400
Jerry Stuckle wrote:
>
> It is either OK to delete an email or it is not. You can't have it
> both ways.
It is *not* OK to silently delete an already accepted email, it does
indeed break SMTP as a reliable protocol ('reliable' as in: 'either we
deliver it or we tell you we didn't').
However, if the Reply-To: is forged, i.e. if it is spam, the
alternative is considerably less OK. Bouncing a spam message simply
delivers *the* *entire* *message* to an innocent third party, having
been laundered through your (presumably legitimate and respectable) mail
server.
So it isn't OK, but there's no alternative to doing it. That's how you
have it both ways.
--
Joe
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141015214430.2eb6a...@jresid.jretrading.com
Re: Recipient validation - WAS: Re: Moderated posts?
On 10/15/2014 12:40 PM, Tanstaafl wrote: > On 10/15/2014 12:06 PM, Jerry Stuckle wrote: >> On 10/15/2014 8:14 AM, Tanstaafl wrote: >>> On 10/14/2014 3:28 PM, Jerry Stuckle wrote: But you just said it was OK to delete emails. > >>> Please don't misquote me. I said it was the *worst case*, meaning, only >>> marginally better than *bouncing* them, which you should never do. >>> >>> I certainly did not say it was 'OK'. > >> You said it was OK. You may try to attack conditions to it - but you >> still said it was OK. > > Easy enough to prove. By all means, quote the actual text of me saying > this was 'OK'... > You said: "However, once a message has been accepted - ie, *after* the DATA phase is complete, it should never be bounced, it should be delivered - or, worse, quarantined, or worst case, deleted (ie, itf it is later found to contain a malicious payload)." It is either OK to delete an email or it is not. You can't have it both ways. If, as according to your other statements, it is not OK to delete emails, then you are violating your own rules by deleting mails - for ANY reason. Your reason is "i.e. if it is later found to contain a malicious payload". My reason is "It is addressed to a non-existent user". Either both are OK or neither is OK. >>> you keep saying that the RECEIVING server 'sends a message back to >>> the originator' - unless maybe you simply have a hard time saying >>> what you really mean, which always causes confusion. > >> it does send a message back to the originator - it may only be a >> status code, but it is still a message. > > The status code is not *sent* anywhere - it is a response directly to > the connecting machine. > Then how does it get back to the sending server? Magic? > It is then the responsibility of that machine that was talking to your > server to pass the response code back to the originating *server* (not > the sender of the email - there is a difference). > I didn't say the sender of the email. > It is then the responsibility of the 'originating server' to generate > the NDR (non-delivery response) email that the sender then receives in > their Inbox. > I never said otherwise. > So, again, no, *your* server doesn't 'send anything back to the > originating server'. > So how does it get back to the sending server? Magic? > I'm done with this thread, since Jerry is free to believe whatever he > wants and run his servers however he wants. > > Thankfully the vast majority of other mail admins use best practices... > > And you still can't quote an RFC which indicates what I am doing "breaks SMTP". That's because there isn't one and I am NOT breaking SMTP. Properly addressed email still gets to its destination. BTW - what happened to all those statistics you quoted? Where are your references for them? Jerry -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/543ec7cc.3030...@attglobal.net
Re: OT: Re: Recipient validation - WAS: Re: Moderated posts?
Tanstaafl wrote: On 10/15/2014 12:50 PM, Miles Fidelman wrote: I'll close by noting that this branch of discussion started with a focus on silently dropping spam, and whether that's a violation of standards. Actually, no, this branch started with a focus on whether or not it is a good idea to break SMTP by accepting email from *invalid recipients* then silently deleting them, as opposed to rejecting them at the RCPT-TO stage. It used to be a clear violation of the various MUST statements re. sending non-delivery messages. It looks like more recent standards now allow for dropping spam as a specific exception case. My position is that: 1. email to invalid recipients should be rejected at the RCPT-TO stage, Easier said then done - at least when a server does relaying, but clearly ideal when possible. 2. under *no* circumstances should mail to invalid recipients be accepted for delivery then silently deleted based solely on that one criteria, and 3. once an email has been accepted for final delivery, every effort should be taken to deliver the message to the recipient, whether to their Inbox clean or tagged as spam (if a spam threshhold is met), or to a spam quarantine, I allow for the very rare 'clear-and-present-danger' exceptional circumstance that, if an after-queue content scanner determines with a very high probability that something contains a malicious payload, an admin might want to not deliver it to the recipient. But, I would also argue that it should go into a quarantine that only the admin has access to, and never just silently deleted. But, as Jerry says, that is just my opinion... Generally agree with you in principle. And that's certainly the standards-compliant policy. In practice I support a few dozen mailing lists - operational necessity dictates dropping a lot of stuff silently. Cheers -- In theory, there is no difference between theory and practice. In practice, there is. Yogi Berra -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/543ec757.80...@meetinghouse.net
Re: Recipient validation - WAS: Re: Moderated posts?
On 10/15/2014 12:34 PM, The Wanderer wrote: > On 10/15/2014 at 12:06 PM, Jerry Stuckle wrote: > >> On 10/15/2014 8:14 AM, Tanstaafl wrote: >> >>> On 10/14/2014 3:28 PM, Jerry Stuckle >>> wrote: > But you just said it was OK to delete emails. >>> >>> Please don't misquote me. I said it was the *worst case*, meaning, >>> only marginally better than *bouncing* them, which you should never >>> do. >>> >>> I certainly did not say it was 'OK'. >> >> You said it was OK. You may try to attack conditions to it - but >> you still said it was OK. > > In a quick search, I haven't been able to find a mail from him which > uses the term "OK", prior to the quoted one which is responding to your > use of that term. > > He did say (in close paraphrase) that there are circumstances in which > silently deleting received mails can be barely acceptable. That's a far > cry from saying that it's "OK", either in the modern colloquial sense or > in the literal original sense of "all correct". > I said NOTHING about security. I just don't want them to know what the valid email addresses are. >>> >>> In my mind saying 'I am doing this because I don't want them to >>> know what the valid email addresses are' is the exact same thing as >>> saying 'I am doing this for security purposes.'. >> >> It has nothing to do with security, no matter is in your mind. > > What is the non-security-related reason why you don't want them to know > what the valid E-mail addresses are? > Spammers buy and sell lists of email addresses. "Clean lists" - that is, ones with few invalid email addresses, are worth more and are used more than "dirty lists". Spammers often test email servers by sending email to garbage addresses, to see if they get a bounce. If they don't, they know the server does not drop emails, and any address in that domain is suspect. So the domain doesn't make a lot of the "clean" lists. > I suspect that the reason is something which Tanstaafl would classify as > falling under "security purposes". > There is no security involved here. Simply another means of discouraging SPAM. > Even if you don't come to agreement on whether that reason is a security > reason, it might still be easier to "agree to disagree" if there's a > clear understanding about exactly what you're disagreeing over, rather > than just conflicting assertions about some consequence of that > underlying point. > He thinks what I am doing "breaks SMTP" - but he can't point to any RFC I am violating. > Please explain what is *Seriously Fraudulent* or *otherwise > inappropriate* about a typo in the recipient address of an > otherwise perfectly legitimate email, Jerry. >>> How many valid emails do you get to a bad email address? >>> >>> Please answer the question. >> >> Any email to a bad email address is fraudulent and/or inappropriate. > > That's just repeating the assertion, not answering the question. It does > not provide the requested explanation. > > What is fraudulent about a typo? > > What is inappropriate about a typo? > Nothing. But if you get a lot of typos, then you should be looking for better quality customers. I don't see that at all in our logs. All I see are fraudulent and/or inappropriate emails to addresses which aren't even close to the ones on the servers. Jerry -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/543ec5fc.20...@attglobal.net
Re: OT: Re: Recipient validation - WAS: Re: Moderated posts?
On 10/15/2014 12:50 PM, Miles Fidelman wrote: > I'll close by noting that this branch of discussion started with a focus > on silently dropping spam, and whether that's a violation of standards. Actually, no, this branch started with a focus on whether or not it is a good idea to break SMTP by accepting email from *invalid recipients* then silently deleting them, as opposed to rejecting them at the RCPT-TO stage. > It used to be a clear violation of the various MUST statements re. > sending non-delivery messages. It looks like more recent standards now > allow for dropping spam as a specific exception case. My position is that: 1. email to invalid recipients should be rejected at the RCPT-TO stage, 2. under *no* circumstances should mail to invalid recipients be accepted for delivery then silently deleted based solely on that one criteria, and 3. once an email has been accepted for final delivery, every effort should be taken to deliver the message to the recipient, whether to their Inbox clean or tagged as spam (if a spam threshhold is met), or to a spam quarantine, I allow for the very rare 'clear-and-present-danger' exceptional circumstance that, if an after-queue content scanner determines with a very high probability that something contains a malicious payload, an admin might want to not deliver it to the recipient. But, I would also argue that it should go into a quarantine that only the admin has access to, and never just silently deleted. But, as Jerry says, that is just my opinion... -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/543eb3f3.6050...@libertytrek.org
Re: OT: Re: Recipient validation - WAS: Re: Moderated posts?
Joel Rees wrote:
On Wed, Oct 15, 2014 at 9:01 PM, Miles Fidelman
wrote:
Tanstaafl wrote:
On 10/14/2014 1:58 PM, Miles Fidelman wrote:
Well, this really is OT for debian-users, but Turns out that SMTP
WAS/IS intended to be reliable.
Reliable, absolutely. 100% reliable? That simply isn't possible when
people are involved in the equation (people mis-configure servers -
whether accidentally, through ignorance, or intentionally (just because
that is the way they want it).
I'd always lumped SMTP in the category of unreliable protocols, w/o
guaranteed delivery
The protocol itself is extremely reliable. It is what people *do* with
it that can cause it to become less reliable/resilient.
There are three ways in which machines can be unreliable.
One, they can break.
Two, they can do what they are told to do, but what they are told to
do can be wrong.
Three, they can operate in a context in which they were not designed to operate.
Oh come on, there are lots more ways that PROTOCOLS can be unreliable.
We're talking about an environment plagued with noise, congestion, bit
errors, routing errors, filtering - all kinds of things that are
probabilistic in nature.
"Unreliable" protocols are generally 'fire-and-forget' in nature (e.g.,
UDP) and promise, at most, "best efforts."
"Reliable" protocols are those that include end-to-end (or, more
accurately, peer-to-peer) error checking, ACKs and NACKs,
retransmission, and so forth. In a protocol context, "reliable" means,
essentially, 'once I get an ACK, I can assume that my PDU has been
delivered to my peer' - and has nothing to do with what happens beyond that.
That's one of the reasons the Requests For Comments were RFCs and not
standards dictated from on high (like many of the earlier network
definitions that ended up too inflexible).
Ummm no. RFCs were RFCs because that's how the early ARPANET R&D
community, and its leadership decided to conduct their business, and the
model stuck.
There is a technical distinction between "best efforts" (unreliable)
protocols, such as IP ('fire and forget' if you will), and "reliable"
protocols, such as TCP (with explicit acks and retransmits).
At least in the technical circles I run in (BBN - you know, we built the
ARPANET; Ray Tomlinson, who coined use of the @ sign in email nominally
worked for me, for a short period - in a matrixy version of "worked for"),
SMTP is usually discussed as providing a "best efforts" (unreliable) service
-- which, in reality, it is (particularly in real world configurations where
mail often gets relayed through multiple servers).
So.. I was just a bit surprised to go back and read the RFC and discover
that SMTP is explicitly intended to provide a reliable service.
If it is, that has changed.
Umm no. The goal statement hasn't changed. Limitations to that
goal have been elaborated on - i.e., specific limits and exceptions to
that reliability have been elaborated on. But, on the whole, the notion
of peer-to-peer transmission of email, as a reliable service, with
acks/nacks/retransmission/error messages/etc/, remains unchanged.
Elsewhere from the part you quoted, there used to be an explanation of
the self-contradictory nature of the requirements.
Specifically, machines cannot actually (the illusions of PKI becoming
widely accepted notwithstanding) certify delivery. That requires a
human at both ends of the chain, in addition to the possibly human
sender and recipient. RFC 821 messages were intended not to require
any human in the chain.
If that has changed, it would be the unreasoning demands of people who
want e-mail to perfect in ways snail mail only almost could be in the
best of times: people who want to be able to do things like sue other
people for not complying with obscure rules when informed of those
rules by e-mail.
Exactly. RFC 821 and its successors do not address human-to-human
communications, they specify a reliable protocol for MTA-to-MTA
communication. Period.
I'll close by noting that this branch of discussion started with a focus
on silently dropping spam, and whether that's a violation of standards.
It used to be a clear violation of the various MUST statements re.
sending non-delivery messages. It looks like more recent standards now
allow for dropping spam as a specific exception case.
Miles Fidelman
--
In theory, there is no difference between theory and practice.
In practice, there is. Yogi Berra
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/543ea5ea.1030...@meetinghouse.net
Re: Recipient validation - WAS: Re: Moderated posts?
On 10/15/2014 12:06 PM, Jerry Stuckle wrote: > On 10/15/2014 8:14 AM, Tanstaafl wrote: >> On 10/14/2014 3:28 PM, Jerry Stuckle wrote: >>> But you just said it was OK to delete emails. >> Please don't misquote me. I said it was the *worst case*, meaning, only >> marginally better than *bouncing* them, which you should never do. >> >> I certainly did not say it was 'OK'. > You said it was OK. You may try to attack conditions to it - but you > still said it was OK. Easy enough to prove. By all means, quote the actual text of me saying this was 'OK'... >> you keep saying that the RECEIVING server 'sends a message back to >> the originator' - unless maybe you simply have a hard time saying >> what you really mean, which always causes confusion. > it does send a message back to the originator - it may only be a > status code, but it is still a message. The status code is not *sent* anywhere - it is a response directly to the connecting machine. It is then the responsibility of that machine that was talking to your server to pass the response code back to the originating *server* (not the sender of the email - there is a difference). It is then the responsibility of the 'originating server' to generate the NDR (non-delivery response) email that the sender then receives in their Inbox. So, again, no, *your* server doesn't 'send anything back to the originating server'. I'm done with this thread, since Jerry is free to believe whatever he wants and run his servers however he wants. Thankfully the vast majority of other mail admins use best practices... -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/543ea368.8000...@libertytrek.org
Re: Recipient validation - WAS: Re: Moderated posts?
On 10/15/2014 12:25 PM, The Wanderer wrote: > On 10/15/2014 at 12:11 PM, Jerry Stuckle wrote: >> You're limiting it too much. From Dictionary.com: >> >> obscurity >> noun, plural obscurities. >> 1. the state or quality of being obscure. >> 2. the condition of being unknown: >> ... > That's a definition of "obscurity", which is indeed fairly broad. Thanks, saved me the trouble - although I don't expect Jerry to 'get it', so this is probably a waste of everyones time to pursue. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/543ea18f.9050...@libertytrek.org
Re: Recipient validation - WAS: Re: Moderated posts?
On 10/15/2014 at 12:06 PM, Jerry Stuckle wrote: > On 10/15/2014 8:14 AM, Tanstaafl wrote: > >> On 10/14/2014 3:28 PM, Jerry Stuckle >> wrote: >>> But you just said it was OK to delete emails. >> >> Please don't misquote me. I said it was the *worst case*, meaning, >> only marginally better than *bouncing* them, which you should never >> do. >> >> I certainly did not say it was 'OK'. > > You said it was OK. You may try to attack conditions to it - but > you still said it was OK. In a quick search, I haven't been able to find a mail from him which uses the term "OK", prior to the quoted one which is responding to your use of that term. He did say (in close paraphrase) that there are circumstances in which silently deleting received mails can be barely acceptable. That's a far cry from saying that it's "OK", either in the modern colloquial sense or in the literal original sense of "all correct". >>> I said NOTHING about security. I just don't want them to know >>> what the valid email addresses are. >> >> In my mind saying 'I am doing this because I don't want them to >> know what the valid email addresses are' is the exact same thing as >> saying 'I am doing this for security purposes.'. > > It has nothing to do with security, no matter is in your mind. What is the non-security-related reason why you don't want them to know what the valid E-mail addresses are? I suspect that the reason is something which Tanstaafl would classify as falling under "security purposes". Even if you don't come to agreement on whether that reason is a security reason, it might still be easier to "agree to disagree" if there's a clear understanding about exactly what you're disagreeing over, rather than just conflicting assertions about some consequence of that underlying point. Please explain what is *Seriously Fraudulent* or *otherwise inappropriate* about a typo in the recipient address of an otherwise perfectly legitimate email, Jerry. >> >>> How many valid emails do you get to a bad email address? >> >> Please answer the question. > > Any email to a bad email address is fraudulent and/or inappropriate. That's just repeating the assertion, not answering the question. It does not provide the requested explanation. What is fraudulent about a typo? What is inappropriate about a typo? -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Recipient validation - WAS: Re: Moderated posts?
On 10/15/2014 at 12:11 PM, Jerry Stuckle wrote: > On 10/15/2014 10:17 AM, The Wanderer wrote: > >> On 10/14/2014 at 03:28 PM, Jerry Stuckle wrote: >>> Then what is that if it isn't "obscurity"? >> >> "Security by obscurity" isn't "no one knows the password" or "no >> one knows the account name"; it's something more like "no one knows >> there's a place to enter an account name or a password". > > You're limiting it too much. From Dictionary.com: > > obscurity > noun, plural obscurities. > 1. the state or quality of being obscure. > 2. the condition of being unknown: > ... That's a definition of "obscurity", which is indeed fairly broad. It's not a definition of "security by obscurity", which is considerably more narrow than the generic definition of "obscurity" would indicate. In many contexts, the use of the jargon phrase "security by obscurity" occurs specifically in order to draw on that more narrow definition. I believe that this is one such context. (I think that I also believe that using "security by obscurity" with a broader sense than that narrow one is inappropriate, because it introduces ambiguity as to which meaning is intended, and is therefore likely to be confusing to a potential reader. But that's a bit of a tangent.) Invoking the generic definition of "obscurity" in the face of a use of the jargon phrase "security by obscurity" is completely missing the intent, and the sense of that phrase. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Recipient validation - WAS: Re: Moderated posts?
On 10/15/2014 10:17 AM, The Wanderer wrote: > On 10/14/2014 at 03:28 PM, Jerry Stuckle wrote: > >> On 10/14/2014 12:03 PM, Tanstaafl wrote: >> >>> On 10/14/2014 11:17 AM, Jerry Stuckle >>> wrote: > Wrong on two counts. First of all, the false notion "Security through obscurity *never* works". This has nothing to do with security. > And BTW, that statement is also wrong - why do you think people are encouraged to use obscure passwords if it doesn't work? But that's another subject. >>> >>> Lol! Not even in the same ballpark, Jerry. Passwords, by their >>> very nature, are intended to be difficult/impossible to 'guess'. >>> >>> To suggest that this is even in the same universe as 'security >>> through obscurity' is ludicrous. >> >> Then what is that if it isn't "obscurity"? > > "Security by obscurity" isn't "no one knows the password" or "no one > knows the account name"; it's something more like "no one knows there's > a place to enter an account name or a password". > You're limiting it too much. From Dictionary.com: obscurity noun, plural obscurities. 1. the state or quality of being obscure. 2. the condition of being unknown: ... A complex password is, by definition, obscure according to #2. And easily guessable password is not obscure, nor is it secure. > It isn't "no one knows how to unlock the door"; it's "no one knows where > the door is", or even closer, "no one knows that there even is a door". > See above. > (There's a mall near where I live which has an out-of-the-way door which > is never locked at any hour, and which does not appear to be covered by > security cameras. As far as I can tell, the after-hours security there > relies entirely on the fact that the general public does not know the > door exists. That's security by obscurity.) > That's one example. > I'm not entirely positive on which side of that distinction this > situation falls, overall. Keeping passwords secret is definitely not > "security by obscurity", but concealing the fact that a given account > exists may arguably be. > See above. Jerry -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/543e9cb5.9020...@attglobal.net
Re: Recipient validation - WAS: Re: Moderated posts?
On 10/15/2014 8:14 AM, Tanstaafl wrote: > On 10/14/2014 3:28 PM, Jerry Stuckle wrote: >> On 10/14/2014 12:03 PM, Tanstaafl wrote: >>> On 10/14/2014 11:17 AM, Jerry Stuckle wrote: On 10/14/2014 8:05 AM, Tanstaafl wrote: > If you think I'm kidding, please by all means go make these silly > statements on the postfix list and I'll just sit and watch the fun. >>> You don't read very well. This has nothing to do with emails to a valid address. A large amount of that spam goes to invalid addresses. I see them go through the logs regularly. >>> >>> I read fine. The 'silly statements' reference was about your suggestion >>> that it is in any way shape or form 'ok' to *accept* mail to invalid >>> recipients then send it to dev/null. > >> But you just said it was OK to delete emails. > > Please don't misquote me. I said it was the *worst case*, meaning, only > marginally better than *bouncing* them, which you should never do. > > I certainly did not say it was 'OK'. > You said it was OK. You may try to attack conditions to it - but you still said it was OK. Wrong. Rejecting garbage sends a message back to the originator, > >>> No, it doesn't. It closes the connection with a response code. > > > >> I know how it works. > > Apparently not, since you keep saying that the RECEIVING server 'sends a > message back to the originator' - unless maybe you simply have a hard > time saying what you really mean, which always causes confusion. > Yes, I do. And it does send a message back to the originator - it may only be a status code, but it is still a message. >> Now how often do you get an email of 1MB? > > Like a large percentage of businesses, we get mail *all the time* that > is many MB's in size. Even all of the freemailers have very large max > sizes they accept now (I think gmail is up to 25MB or 30MB?). > Provide figures for your claim of "a large percentage of businesses". Seldom do I see messages that big on ANY of my systems. Additionally, often times ISPs will limit the size of messages users can send. And many systems have limits on how much storage email can take up. Just because a couple of free email services accept larger messages does not mean EVERYONE does. > But, I'd say 10-15% of our email traffic consists of messages that are 1MB+ > For my systems, it is < 1%. And the average email size is around 20-30K. > And yes, even lots of spam now has larger attachments (even seen them > over 2MB, though not very often). > Yes, spam with trojans and viruses often have large attachments. But those are quickly taken care of by the antivirus routines. >>> If I reject the mail at the RCPT-TO stage, then I only accepted a few >>> bytes of traffic before terminating the connection with an SMTP response >>> (error) code. The connecting machine then decides whether to pass the >>> response back or not (again, a few bytes at most). > >> That's your option. > > No, it is the right thing to do. > According to which RFC? Until you can point me to what RFC I am violating, it is just your opinion. >>> If you *accept* the mail, then you accepted the entire 1MB of traffic. >>> >>> So, who is responsible for more traffic in such a case? > >> Sure. > > Thank you for acknowledging that at least this argument in support of > breaking recipient validation (that rejecting emails results in more > traffic than accepting/deleting them) is wrong. We're making progress. > You don't recognize sarcasm very well. >> But spammers don't know whether it is a good address or not. > > Nor do they if I reject the transaction way before the RCPT-TO stage, > which postscreen does *very* well, which is what happens most of the time. > Sure they do. They get a status message back indicating the message was rejected and why it was rejected. The fact they DON'T get that message indicates they have found a valid EMAIL address. And validated EMAIL addresses are a spammer's dream. > Also, my understanding is that there the vast majority of spammers no > longer engage in dictionary attacks to harvest valid email addresses. > Your understanding is incorrect. I see it regularly. >> I said NOTHING about security. I just don't want them to know what the >> valid email addresses are. > > In my mind saying 'I am doing this because I don't want them to know > what the valid email addresses are' is the exact same thing as saying 'I > am doing this for security purposes.'. > It has nothing to do with security, no matter is in your mind. >> That way they don't send more SPAM to the good addresses. > > It isn't about how much spam is targeted at your users, it is about how > much gets through, and an effective anti-spam solution block 99+% of it > - *without* breaking SMTP. And again, my understanding is that there the > vast majority of spammers no longer engage in dictionary attacks to > harvest valid email addresses, so you are continuing to break smtp for > your users and
Re: OT: Re: Recipient validation - WAS: Re: Moderated posts?
On Wed, Oct 15, 2014 at 9:01 PM, Miles Fidelman
wrote:
> Tanstaafl wrote:
>>
>> On 10/14/2014 1:58 PM, Miles Fidelman wrote:
>>>
>>> Well, this really is OT for debian-users, but Turns out that SMTP
>>> WAS/IS intended to be reliable.
>>
>> Reliable, absolutely. 100% reliable? That simply isn't possible when
>> people are involved in the equation (people mis-configure servers -
>> whether accidentally, through ignorance, or intentionally (just because
>> that is the way they want it).
>>
>>> I'd always lumped SMTP in the category of unreliable protocols, w/o
>>> guaranteed delivery
>>
>> The protocol itself is extremely reliable. It is what people *do* with
>> it that can cause it to become less reliable/resilient.
There are three ways in which machines can be unreliable.
One, they can break.
Two, they can do what they are told to do, but what they are told to
do can be wrong.
Three, they can operate in a context in which they were not designed to operate.
Unfortunately, most machines operated outside the context in which
they were designed to operate. It's a limitation of design. We are the
designers, and we can't think of everything, therefore we cannot
really design for a real context.
Put another way, any context we can design for is necessarily more
constrained than reality.
Fortunately, most of the contexts we design for are "close enough" to
be useful under many real contexts. But we have to quit being taken by
surprise when our machines hit corner cases, or we end up wasting our
energy being surprised.
That's one of the reasons the Requests For Comments were RFCs and not
standards dictated from on high (like many of the earlier network
definitions that ended up too inflexible).
> There is a technical distinction between "best efforts" (unreliable)
> protocols, such as IP ('fire and forget' if you will), and "reliable"
> protocols, such as TCP (with explicit acks and retransmits).
>
> At least in the technical circles I run in (BBN - you know, we built the
> ARPANET; Ray Tomlinson, who coined use of the @ sign in email nominally
> worked for me, for a short period - in a matrixy version of "worked for"),
> SMTP is usually discussed as providing a "best efforts" (unreliable) service
> -- which, in reality, it is (particularly in real world configurations where
> mail often gets relayed through multiple servers).
>
> So.. I was just a bit surprised to go back and read the RFC and discover
> that SMTP is explicitly intended to provide a reliable service.
If it is, that has changed.
Elsewhere from the part you quoted, there used to be an explanation of
the self-contradictory nature of the requirements.
Specifically, machines cannot actually (the illusions of PKI becoming
widely accepted notwithstanding) certify delivery. That requires a
human at both ends of the chain, in addition to the possibly human
sender and recipient. RFC 821 messages were intended not to require
any human in the chain.
If that has changed, it would be the unreasoning demands of people who
want e-mail to perfect in ways snail mail only almost could be in the
best of times: people who want to be able to do things like sue other
people for not complying with obscure rules when informed of those
rules by e-mail.
> As to "100% reliable" - nothing is 100% reliable.
>
> Miles Fidelman
>
> --
> In theory, there is no difference between theory and practice.
> In practice, there is. Yogi Berra
--
Joel Rees
Be careful when you see conspiracy.
Look first in your own heart,
and ask yourself if you are not your own worst enemy.
Arm yourself with knowledge of yourself.
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/CAAr43iP9t8iJYmPNLkVw_Pg8UAJYHHZeacftZ=fm_rt2cr1...@mail.gmail.com
Re: Recipient validation - WAS: Re: Moderated posts?
On 10/14/2014 at 03:28 PM, Jerry Stuckle wrote: > On 10/14/2014 12:03 PM, Tanstaafl wrote: > >> On 10/14/2014 11:17 AM, Jerry Stuckle >> wrote: >>> Wrong on two counts. First of all, the false notion "Security >>> through obscurity *never* works". This has nothing to do with >>> security. >>> And BTW, that statement is also wrong - why do you think people >>> are encouraged to use obscure passwords if it doesn't work? But >>> that's another subject. >> >> Lol! Not even in the same ballpark, Jerry. Passwords, by their >> very nature, are intended to be difficult/impossible to 'guess'. >> >> To suggest that this is even in the same universe as 'security >> through obscurity' is ludicrous. > > Then what is that if it isn't "obscurity"? "Security by obscurity" isn't "no one knows the password" or "no one knows the account name"; it's something more like "no one knows there's a place to enter an account name or a password". It isn't "no one knows how to unlock the door"; it's "no one knows where the door is", or even closer, "no one knows that there even is a door". (There's a mall near where I live which has an out-of-the-way door which is never locked at any hour, and which does not appear to be covered by security cameras. As far as I can tell, the after-hours security there relies entirely on the fact that the general public does not know the door exists. That's security by obscurity.) I'm not entirely positive on which side of that distinction this situation falls, overall. Keeping passwords secret is definitely not "security by obscurity", but concealing the fact that a given account exists may arguably be. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Recipient validation - WAS: Re: Moderated posts?
On 10/14/2014 3:20 PM, Jerry Stuckle wrote: > On 10/14/2014 11:24 AM, Tanstaafl wrote: >> However, once a message has been accepted - ie, *after* the DATA phase >> is complete, it should never be bounced, it should be delivered - or, >> worse, quarantined, or worst case, deleted (ie, itf it is later found to >> contain a malicious payload). >> >> But I was speaking mainly toward the botnet junk that postscreen is so >> good at rejecting now, and that is the vast majority... > And that is exactly what I do - I delete the email. Right... the 'worst case' (with the exception of bouncing) I mentioned above. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/543e6611.9040...@libertytrek.org
Re: Recipient validation - WAS: Re: Moderated posts?
On 10/14/2014 3:28 PM, Jerry Stuckle wrote: > On 10/14/2014 12:03 PM, Tanstaafl wrote: >> On 10/14/2014 11:17 AM, Jerry Stuckle wrote: >>> On 10/14/2014 8:05 AM, Tanstaafl wrote: If you think I'm kidding, please by all means go make these silly statements on the postfix list and I'll just sit and watch the fun. >> >>> You don't read very well. This has nothing to do with emails to a valid >>> address. A large amount of that spam goes to invalid addresses. I see >>> them go through the logs regularly. >> >> I read fine. The 'silly statements' reference was about your suggestion >> that it is in any way shape or form 'ok' to *accept* mail to invalid >> recipients then send it to dev/null. > But you just said it was OK to delete emails. Please don't misquote me. I said it was the *worst case*, meaning, only marginally better than *bouncing* them, which you should never do. I certainly did not say it was 'OK'. >>> Wrong. Rejecting garbage sends a message back to the originator, >> No, it doesn't. It closes the connection with a response code. > I know how it works. Apparently not, since you keep saying that the RECEIVING server 'sends a message back to the originator' - unless maybe you simply have a hard time saying what you really mean, which always causes confusion. > Now how often do you get an email of 1MB? Like a large percentage of businesses, we get mail *all the time* that is many MB's in size. Even all of the freemailers have very large max sizes they accept now (I think gmail is up to 25MB or 30MB?). But, I'd say 10-15% of our email traffic consists of messages that are 1MB+ And yes, even lots of spam now has larger attachments (even seen them over 2MB, though not very often). >> If I reject the mail at the RCPT-TO stage, then I only accepted a few >> bytes of traffic before terminating the connection with an SMTP response >> (error) code. The connecting machine then decides whether to pass the >> response back or not (again, a few bytes at most). > That's your option. No, it is the right thing to do. >> If you *accept* the mail, then you accepted the entire 1MB of traffic. >> >> So, who is responsible for more traffic in such a case? > Sure. Thank you for acknowledging that at least this argument in support of breaking recipient validation (that rejecting emails results in more traffic than accepting/deleting them) is wrong. We're making progress. > But spammers don't know whether it is a good address or not. Nor do they if I reject the transaction way before the RCPT-TO stage, which postscreen does *very* well, which is what happens most of the time. Also, my understanding is that there the vast majority of spammers no longer engage in dictionary attacks to harvest valid email addresses. > I said NOTHING about security. I just don't want them to know what the > valid email addresses are. In my mind saying 'I am doing this because I don't want them to know what the valid email addresses are' is the exact same thing as saying 'I am doing this for security purposes.'. > That way they don't send more SPAM to the good addresses. It isn't about how much spam is targeted at your users, it is about how much gets through, and an effective anti-spam solution block 99+% of it - *without* breaking SMTP. And again, my understanding is that there the vast majority of spammers no longer engage in dictionary attacks to harvest valid email addresses, so you are continuing to break smtp for your users and getting very little to no real world value out of it. >> Passwords, by their very nature, are intended to be >> difficult/impossible to 'guess'. >> >> To suggest that this is even in the same universe as 'security through >> obscurity' is ludicrous. > Then what is that if it isn't "obscurity"? I didn't say it wasn't 'obscurity', I said it wasn't "*security through obscurity*". The first is a simple word that has a very broad and general meaning. The second has a very specific and limited meaning. >> You don't necessarily need to explictly violate any give RFC to 'break >> SMTP', Jerry. >> >> Breaking recipient validation defacto breaks SMTP. It tells the sending >> server that everything is OK, when it isn't. It allows someone who > Tell me what RFC I am violating. Unless I am violating an RFC, there is > no "breaking" of SMTP. Objection: asked and answered (see directly above). >> No one should. What I do care about is if the President of NBC typos an >> email address to our President when sending an important email, I want >> him to know the email didn't make it. > And what if he sends a letter, but misaddresses the letter? He'll (hopefully) know about it when it gets returned, because his secretary (hopefully) isn't stupid and puts the correct return address on it. >> Please explain what is *Seriously Fraudulent* or *otherwise >> inappropriate* about a typo in the recipient address of an otherwise >> perfectly legitimate email, Jerry. > How many valid email
Re: OT: Re: Recipient validation - WAS: Re: Moderated posts?
Tanstaafl wrote:
On 10/14/2014 1:58 PM, Miles Fidelman wrote:
Well, this really is OT for debian-users, but Turns out that SMTP
WAS/IS intended to be reliable.
Reliable, absolutely. 100% reliable? That simply isn't possible when
people are involved in the equation (people mis-configure servers -
whether accidentally, through ignorance, or intentionally (just because
that is the way they want it).
I'd always lumped SMTP in the category of unreliable protocols, w/o
guaranteed delivery
The protocol itself is extremely reliable. It is what people *do* with
it that can cause it to become less reliable/resilient.
There is a technical distinction between "best efforts" (unreliable)
protocols, such as IP ('fire and forget' if you will), and "reliable"
protocols, such as TCP (with explicit acks and retransmits).
At least in the technical circles I run in (BBN - you know, we built the
ARPANET; Ray Tomlinson, who coined use of the @ sign in email nominally
worked for me, for a short period - in a matrixy version of "worked
for"), SMTP is usually discussed as providing a "best efforts"
(unreliable) service -- which, in reality, it is (particularly in real
world configurations where mail often gets relayed through multiple
servers).
So.. I was just a bit surprised to go back and read the RFC and discover
that SMTP is explicitly intended to provide a reliable service.
As to "100% reliable" - nothing is 100% reliable.
Miles Fidelman
--
In theory, there is no difference between theory and practice.
In practice, there is. Yogi Berra
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/543e6219.6030...@meetinghouse.net
Re: Recipient validation - WAS: Re: Moderated posts?
On 10/14/2014 12:03 PM, Tanstaafl wrote: > The 'silly statements' reference was about your suggestion > that it is in any way shape or form 'ok' to *accept* mail to invalid > recipients then send it to dev/null. Incidentally, yes there may be some circumstances where this could be considered ok... a hobby server, or your own, personal server. Your server, your rules. But I'm talking about mail servers with lots of users who expect to be able to communicate via email effectively and reliably with others on the internet. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/543e4ec5.2000...@libertytrek.org
Re: OT: Re: Recipient validation - WAS: Re: Moderated posts?
On 10/14/2014 1:58 PM, Miles Fidelman wrote: > Well, this really is OT for debian-users, but Turns out that SMTP > WAS/IS intended to be reliable. Reliable, absolutely. 100% reliable? That simply isn't possible when people are involved in the equation (people mis-configure servers - whether accidentally, through ignorance, or intentionally (just because that is the way they want it). > I'd always lumped SMTP in the category of unreliable protocols, w/o > guaranteed delivery The protocol itself is extremely reliable. It is what people *do* with it that can cause it to become less reliable/resilient. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/543e4da8.2060...@libertytrek.org
Re: Recipient validation - WAS: Re: Moderated posts?
On 10/14/2014 12:03 PM, Tanstaafl wrote: > On 10/14/2014 11:17 AM, Jerry Stuckle wrote: >> On 10/14/2014 8:05 AM, Tanstaafl wrote: >>> If you think I'm kidding, please by all means go make these silly >>> statements on the postfix list and I'll just sit and watch the fun. > >> You don't read very well. This has nothing to do with emails to a valid >> address. A large amount of that spam goes to invalid addresses. I see >> them go through the logs regularly. > > I read fine. The 'silly statements' reference was about your suggestion > that it is in any way shape or form 'ok' to *accept* mail to invalid > recipients then send it to dev/null. > But you just said it was OK to delete emails. To bounce all of those invalid addresses not only would further increase the amount of junk on the internet, > >>> That is pure and absolute nonsense. The vast majority of spam comes from >>> botnets, and *rejecting* garbage from these results in ZERO additional >>> smtp traffic. > >> Wrong. Rejecting garbage sends a message back to the originator, > > No, it doesn't. It closes the connection with a response code. > > The system that had opened the connection and was attempting to send the > email is the one responsible for 'sending a message back to the originator'. > > Well, *if* the system talking to your server is the originating server, > that is. > > If, on the other hand, there were relays involvbed, then it would simply > relay the response code back down the chain until it got to the > originating server. > > This is very simple to validate. I suggest you do so before compounding > your error in public. > I know how it works. And it all depends on when the message is rejected - if it is rejected. Accepting it and deleting it adds no extra overhead to the network. >> increasing the traffic. Simply dropping them, as I do, does not. > > Given an identical mail transaction, with an email with a size of 1MB: > Now how often do you get an email of 1MB? > If I reject the mail at the RCPT-TO stage, then I only accepted a few > bytes of traffic before terminating the connection with an SMTP response > (error) code. The connecting machine then decides whether to pass the > response back or not (again, a few bytes at most). > That's your option. > If you *accept* the mail, then you accepted the entire 1MB of traffic. > > So, who is responsible for more traffic in such a case? > Sure. But spammers don't know whether it is a good address or not. but by not replying, servers tell the spammers what are valid email addresses. > >>> More nonsense. Security through obscurity *never* works, and only, in >>> this case totally breaks SMTP. > >> Wrong on two counts. First of all, the false notion "Security through >> obscurity *never* works". This has nothing to do with security. > > You said you were concerned about telling spammers valid emails. Why are > you concerned about that if not from a security perspective? > I said NOTHING about security. I just don't want them to know what the valid email addresses are. That way they don't send more SPAM to the good addresses. Security is not a problem. People log in to their mailboxes with ids that are not necessarily the same as their email address. >> And BTW, that statement is also wrong - why do you think people are >> encouraged to use obscure passwords if it doesn't work? But that's >> another subject. > > Lol! Not even in the same ballpark, Jerry. Passwords, by their very > nature, are intended to be difficult/impossible to 'guess'. > > To suggest that this is even in the same universe as 'security through > obscurity' is ludicrous. > Then what is that if it isn't "obscurity"? >> On the second count - please point out exactly which RFC I am violating >> that "breaks SMTP". > > You don't necessarily need to explictly violate any give RFC to 'break > SMTP', Jerry. > > Breaking recipient validation defacto breaks SMTP. It tells the sending > server that everything is OK, when it isn't. It allows someone who > Tell me what RFC I am violating. Unless I am violating an RFC, there is no "breaking" of SMTP. Finally, as for "...undermine confidence in the reliability of the Internet's mail systems..." - it hasn't been reliable since spammers virtually took over the email. And even when emails were rejected, it still was no indication the recipient got the message. >>> >>> Of course it wasn't, but it was certainly a positive indication that the >>> recipient did *not* receive it (as long as the sending server is >>> properly configured). > >> And why should I care if a bot finds out the message has not been received? > > No one should. What I do care about is if the President of NBC typos an > email address to our President when sending an important email, I want > him to know the email didn't make it. > And what if he sends a letter, but misaddresses the letter? BTW - by definition, a
Re: Recipient validation - WAS: Re: Moderated posts?
On 10/14/2014 11:24 AM, Tanstaafl wrote: > On 10/14/2014 10:52 AM, Jonathan Dowland wrote: >> On Tue, Oct 14, 2014 at 10:48:38AM -0400, Tanstaafl wrote: >>> Rejecting will actually *reduce* traffic, because it doesn't accept the >>> entire messages, it slams the door at the RCPT-TO stage. > >> Rejection can happen after the DATA phase as well. It's better if spam can be >> identified and rejected before this phase, for the reasons you have >> identified; >> but it isn't always possible. > > Well... a message can be rejected up to the END of the data phase - but, > yes, if you have a pre-queue content filer, you can certainly end up > rejecting something after receiving 99% of the data. > > However, once a message has been accepted - ie, *after* the DATA phase > is complete, it should never be bounced, it should be delivered - or, > worse, quarantined, or worst case, deleted (ie, itf it is later found to > contain a malicious payload). > > But I was speaking mainly toward the botnet junk that postscreen is so > good at rejecting now, and that is the vast majority... > > And that is exactly what I do - I delete the email. Jerry -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/543d7774.1040...@attglobal.net
Re: Recipient validation - WAS: Re: Moderated posts?
On 10/14/2014 1:31 PM, Joel Rees wrote: > You're talking past each other. No, we're not, Jerry is arguing arguing against recipient validation on mail servers, and I'm correcting some of the bad/mis-information he is relying on when trying to support his argument. > Still, the current "standard" e-mail protocols were never meant to be > either reliable or secure, and their is a very good reason for that. > People may not be as reliable as machines in executing protocols, but > they cannot be 100% reliable, and only people can certify things. And since neither of us said anything to the contrary, and in fact admitted pretty much just that, your 'me too!' is duly noted. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/543d6850.6040...@libertytrek.org
OT: Re: Recipient validation - WAS: Re: Moderated posts?
Well, this really is OT for debian-users, but Turns out that SMTP
WAS/IS intended to be reliable.
I'd always lumped SMTP in the category of unreliable protocols, w/o
guaranteed delivery - but then, being a bit pedantic, I went back to the
source RFC 821, SMTP, authored by Jon Postel, and found a few tidbits...
1. INTRODUCTION
The objective of Simple Mail Transfer Protocol (SMTP) is to transfer
mail reliably and efficiently.
SMTP is independent of the particular transmission subsystem and
requires only a reliable ordered data stream channel.
4.2. SMTP REPLIES
Replies to SMTP commands are devised to ensure the synchronization
of requests and actions in the process of mail transfer, and to
guarantee that the sender-SMTP always knows the state of the
receiver-SMTP. Every command must generate exactly one reply.
---
The latest spec, RFC5321 goes on to say:
6. Problem Detection and Handling
6.1. Reliable Delivery and Replies by Email
When the receiver-SMTP accepts a piece of mail (by sending a "250 OK"
message in response to DATA), it is accepting responsibility for
delivering or relaying the message. It must take this responsibility
seriously. It MUST NOT lose the message for frivolous reasons, such
as because the host later crashes or because of a predictable
resource shortage. Some reasons that are not considered frivolous
are discussed in the next subsection and in Section 7.8.
If there is a delivery failure after acceptance of a message, the
receiver-SMTP MUST formulate and mail a notification message. This
notification MUST be sent using a null ("<>") reverse-path in the
envelope. The recipient of this notification MUST be the address
from the envelope return path (or the Return-Path: line). However, .
Mind you, we're only talking about transferring mail reliably from SMTP
peer to SMTP peer (or perhaps, file system on the sending system to file
system on the receiving system); and RFC821 does not address multi-hop
mail transfer.
Miles Fidelman
Joel Rees wrote:
Oh, dear. Somebody is WRONG on the Internet!
You're talking past each other.
Still, the current "standard" e-mail protocols were never meant to be
either reliable or secure, and their is a very good reason for that.
People may not be as reliable as machines in executing protocols, but
they cannot be 100% reliable, and only people can certify things.
2014/10/15 1:04 "Tanstaafl" >:
>
> On 10/14/2014 11:17 AM, Jerry Stuckle > wrote:
> > On 10/14/2014 8:05 AM, Tanstaafl wrote:
> >> If you think I'm kidding, please by all means go make these silly
> >> statements on the postfix list and I'll just sit and watch the fun.
>
> > You don't read very well. This has nothing to do with emails to a
valid
> > address. A large amount of that spam goes to invalid addresses.
I see
> > them go through the logs regularly.
>
> I read fine. The 'silly statements' reference was about your suggestion
> that it is in any way shape or form 'ok' to *accept* mail to invalid
> recipients then send it to dev/null.
>
> >>> To bounce all of those invalid addresses not only would further
> >>> increase the amount of junk on the internet,
>
> >> That is pure and absolute nonsense. The vast majority of spam
comes from
> >> botnets, and *rejecting* garbage from these results in ZERO
additional
> >> smtp traffic.
>
> > Wrong. Rejecting garbage sends a message back to the originator,
>
> No, it doesn't. It closes the connection with a response code.
>
> The system that had opened the connection and was attempting to send the
> email is the one responsible for 'sending a message back to the
originator'.
>
> Well, *if* the system talking to your server is the originating server,
> that is.
>
> If, on the other hand, there were relays involvbed, then it would simply
> relay the response code back down the chain until it got to the
> originating server.
>
> This is very simple to validate. I suggest you do so before compounding
> your error in public.
>
> > increasing the traffic. Simply dropping them, as I do, does not.
>
> Given an identical mail transaction, with an email with a size of 1MB:
>
> If I reject the mail at the RCPT-TO stage, then I only accepted a few
> bytes of traffic before terminating the connection with an SMTP response
> (error) code. The connecting machine then decides whether to pass the
> response back or not (again, a few bytes at most).
>
> If you *accept* the mail, then you accepted the entire 1MB of traffic.
>
> So, who is responsible for more traffic in such a case?
>
> >>> but by not replying, servers tell the spammers what are valid email
> >>> addresses.
>
> >> More nonsense. Security through obscurity *never* works, and only, in
> >> this case totally breaks SMTP.
>
> > Wrong on two counts. First of all, the false notion "Security thro
Re: Recipient validation - WAS: Re: Moderated posts?
Oh, dear. Somebody is WRONG on the Internet! You're talking past each other. Still, the current "standard" e-mail protocols were never meant to be either reliable or secure, and their is a very good reason for that. People may not be as reliable as machines in executing protocols, but they cannot be 100% reliable, and only people can certify things. 2014/10/15 1:04 "Tanstaafl" : > > On 10/14/2014 11:17 AM, Jerry Stuckle wrote: > > On 10/14/2014 8:05 AM, Tanstaafl wrote: > >> If you think I'm kidding, please by all means go make these silly > >> statements on the postfix list and I'll just sit and watch the fun. > > > You don't read very well. This has nothing to do with emails to a valid > > address. A large amount of that spam goes to invalid addresses. I see > > them go through the logs regularly. > > I read fine. The 'silly statements' reference was about your suggestion > that it is in any way shape or form 'ok' to *accept* mail to invalid > recipients then send it to dev/null. > > >>> To bounce all of those invalid addresses not only would further > >>> increase the amount of junk on the internet, > > >> That is pure and absolute nonsense. The vast majority of spam comes from > >> botnets, and *rejecting* garbage from these results in ZERO additional > >> smtp traffic. > > > Wrong. Rejecting garbage sends a message back to the originator, > > No, it doesn't. It closes the connection with a response code. > > The system that had opened the connection and was attempting to send the > email is the one responsible for 'sending a message back to the originator'. > > Well, *if* the system talking to your server is the originating server, > that is. > > If, on the other hand, there were relays involvbed, then it would simply > relay the response code back down the chain until it got to the > originating server. > > This is very simple to validate. I suggest you do so before compounding > your error in public. > > > increasing the traffic. Simply dropping them, as I do, does not. > > Given an identical mail transaction, with an email with a size of 1MB: > > If I reject the mail at the RCPT-TO stage, then I only accepted a few > bytes of traffic before terminating the connection with an SMTP response > (error) code. The connecting machine then decides whether to pass the > response back or not (again, a few bytes at most). > > If you *accept* the mail, then you accepted the entire 1MB of traffic. > > So, who is responsible for more traffic in such a case? > > >>> but by not replying, servers tell the spammers what are valid email > >>> addresses. > > >> More nonsense. Security through obscurity *never* works, and only, in > >> this case totally breaks SMTP. > > > Wrong on two counts. First of all, the false notion "Security through > > obscurity *never* works". This has nothing to do with security. > > You said you were concerned about telling spammers valid emails. Why are > you concerned about that if not from a security perspective? > > > And BTW, that statement is also wrong - why do you think people are > > encouraged to use obscure passwords if it doesn't work? But that's > > another subject. > > Lol! Not even in the same ballpark, Jerry. Passwords, by their very > nature, are intended to be difficult/impossible to 'guess'. > > To suggest that this is even in the same universe as 'security through > obscurity' is ludicrous. > > > On the second count - please point out exactly which RFC I am violating > > that "breaks SMTP". > > You don't necessarily need to explictly violate any give RFC to 'break > SMTP', Jerry. > > Breaking recipient validation defacto breaks SMTP. It tells the sending > server that everything is OK, when it isn't. It allows someone who > > >>> Finally, as for "...undermine confidence in the reliability of the > >>> Internet's mail systems..." - it hasn't been reliable since spammers > >>> virtually took over the email. And even when emails were rejected, it > >>> still was no indication the recipient got the message. > >> > >> Of course it wasn't, but it was certainly a positive indication that the > >> recipient did *not* receive it (as long as the sending server is > >> properly configured). > > > And why should I care if a bot finds out the message has not been received? > > No one should. What I do care about is if the President of NBC typos an > email address to our President when sending an important email, I want > him to know the email didn't make it. > > >>> BTW - by definition, any messages to any of the domains I manage without > >>> a valid email address are "seriously fraudulent or otherwise inappropriate". > >>> > >> Really? > > > > Yes > > > >> So when the President/CEO of XYZ Corporation, who does business with a > >> customer whose domain happens to be managed by you, accidentally typos > >> an email address, you consider that a 'seriously fraudulent or otherwise > >> inappropriate' email? > > > Yes. > > Please explain what is *Seriously Fraudulent* or *ot
Re: Recipient validation - WAS: Re: Moderated posts?
On 10/14/2014 11:17 AM, Jerry Stuckle wrote: > On 10/14/2014 8:05 AM, Tanstaafl wrote: >> If you think I'm kidding, please by all means go make these silly >> statements on the postfix list and I'll just sit and watch the fun. > You don't read very well. This has nothing to do with emails to a valid > address. A large amount of that spam goes to invalid addresses. I see > them go through the logs regularly. I read fine. The 'silly statements' reference was about your suggestion that it is in any way shape or form 'ok' to *accept* mail to invalid recipients then send it to dev/null. >>> To bounce all of those invalid addresses not only would further >>> increase the amount of junk on the internet, >> That is pure and absolute nonsense. The vast majority of spam comes from >> botnets, and *rejecting* garbage from these results in ZERO additional >> smtp traffic. > Wrong. Rejecting garbage sends a message back to the originator, No, it doesn't. It closes the connection with a response code. The system that had opened the connection and was attempting to send the email is the one responsible for 'sending a message back to the originator'. Well, *if* the system talking to your server is the originating server, that is. If, on the other hand, there were relays involvbed, then it would simply relay the response code back down the chain until it got to the originating server. This is very simple to validate. I suggest you do so before compounding your error in public. > increasing the traffic. Simply dropping them, as I do, does not. Given an identical mail transaction, with an email with a size of 1MB: If I reject the mail at the RCPT-TO stage, then I only accepted a few bytes of traffic before terminating the connection with an SMTP response (error) code. The connecting machine then decides whether to pass the response back or not (again, a few bytes at most). If you *accept* the mail, then you accepted the entire 1MB of traffic. So, who is responsible for more traffic in such a case? >>> but by not replying, servers tell the spammers what are valid email >>> addresses. >> More nonsense. Security through obscurity *never* works, and only, in >> this case totally breaks SMTP. > Wrong on two counts. First of all, the false notion "Security through > obscurity *never* works". This has nothing to do with security. You said you were concerned about telling spammers valid emails. Why are you concerned about that if not from a security perspective? > And BTW, that statement is also wrong - why do you think people are > encouraged to use obscure passwords if it doesn't work? But that's > another subject. Lol! Not even in the same ballpark, Jerry. Passwords, by their very nature, are intended to be difficult/impossible to 'guess'. To suggest that this is even in the same universe as 'security through obscurity' is ludicrous. > On the second count - please point out exactly which RFC I am violating > that "breaks SMTP". You don't necessarily need to explictly violate any give RFC to 'break SMTP', Jerry. Breaking recipient validation defacto breaks SMTP. It tells the sending server that everything is OK, when it isn't. It allows someone who >>> Finally, as for "...undermine confidence in the reliability of the >>> Internet's mail systems..." - it hasn't been reliable since spammers >>> virtually took over the email. And even when emails were rejected, it >>> still was no indication the recipient got the message. >> >> Of course it wasn't, but it was certainly a positive indication that the >> recipient did *not* receive it (as long as the sending server is >> properly configured). > And why should I care if a bot finds out the message has not been received? No one should. What I do care about is if the President of NBC typos an email address to our President when sending an important email, I want him to know the email didn't make it. >>> BTW - by definition, any messages to any of the domains I manage without >>> a valid email address are "seriously fraudulent or otherwise inappropriate". >>> >> Really? > > Yes > >> So when the President/CEO of XYZ Corporation, who does business with a >> customer whose domain happens to be managed by you, accidentally typos >> an email address, you consider that a 'seriously fraudulent or otherwise >> inappropriate' email? > Yes. Please explain what is *Seriously Fraudulent* or *otherwise inappropriate* about a typo in the recipient address of an otherwise perfectly legitimate email, Jerry. > Just like a misaddressed letter at the post office. It will not > necessarily be returned. While not a perfect analogy (big difference between totally automated systems and systems that have imperfect humans (postoffice workers) in the mix), it is still generally wrong. I have had more than one letter/package returned because it was misaddressed in my lifetime - but of course, this does require that you actually put a valid return address on it. But I
Re: Recipient validation - WAS: Re: Moderated posts?
On 10/14/2014 10:52 AM, Jonathan Dowland wrote: > On Tue, Oct 14, 2014 at 10:48:38AM -0400, Tanstaafl wrote: >> Rejecting will actually *reduce* traffic, because it doesn't accept the >> entire messages, it slams the door at the RCPT-TO stage. > Rejection can happen after the DATA phase as well. It's better if spam can be > identified and rejected before this phase, for the reasons you have > identified; > but it isn't always possible. Well... a message can be rejected up to the END of the data phase - but, yes, if you have a pre-queue content filer, you can certainly end up rejecting something after receiving 99% of the data. However, once a message has been accepted - ie, *after* the DATA phase is complete, it should never be bounced, it should be delivered - or, worse, quarantined, or worst case, deleted (ie, itf it is later found to contain a malicious payload). But I was speaking mainly toward the botnet junk that postscreen is so good at rejecting now, and that is the vast majority... -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/543d4025.2010...@libertytrek.org
Re: Recipient validation - WAS: Re: Moderated posts?
On 10/14/2014 8:05 AM, Tanstaafl wrote: > On 10/13/2014 9:53 PM, Jerry Stuckle wrote: >> Not a grey area at all. "...dropping mail > without notification of the >> sender is permitted...". As for the "...long tradition and community >> expectations..." - that's nice, but according to some estimates, >> spammers now account for over 90% of the email traffic on the internet. > > And there are very simple ways to eliminate 90+% of that very simply > (postfix+postscreen, without any additional tools), without risk of > rejecting *any* legitimate email, and without *breaking SMTP*, which is > what you are advocating. > > By adding a few simple additional tools (amavisd-new+spamassassin), you > can easily deal with the remaining 9.9%... > > If you think I'm kidding, please by all means go make these silly > statements on the postfix list and I'll just sit and watch the fun. > You don't read very well. This has nothing to do with emails to a valid address. A large amount of that spam goes to invalid addresses. I see them go through the logs regularly. >> To bounce all of those invalid addresses not only would further >> increase the amount of junk on the internet, > > That is pure and absolute nonsense. The vast majority of spam comes from > botnets, and *rejecting* garbage from these results in ZERO additional > smtp traffic. > Wrong. Rejecting garbage sends a message back to the originator, increasing the traffic. Simply dropping them, as I do, does not. >> but by not replying, servers tell the spammers what are valid email >> addresses. > > More nonsense. Security through obscurity *never* works, and only, in > this case totally breaks SMTP. > Wrong on two counts. First of all, the false notion "Security through obscurity *never* works". This has nothing to do with security. And BTW, that statement is also wrong - why do you think people are encouraged to use obscure passwords if it doesn't work? But that's another subject. On the second count - please point out exactly which RFC I am violating that "breaks SMTP". >> Finally, as for "...undermine confidence in the reliability of the >> Internet's mail systems..." - it hasn't been reliable since spammers >> virtually took over the email. And even when emails were rejected, it >> still was no indication the recipient got the message. > > Of course it wasn't, but it was certainly a positive indication that the > recipient did *not* receive it (as long as the sending server is > properly configured). > And why should I care if a bot finds out the message has not been received? >> There is, and never has been a reliable end-to-end verification of email >> messages. > > Well, that at least is true. > >> BTW - by definition, any messages to any of the domains I manage without >> a valid email address are "seriously fraudulent or otherwise inappropriate". > > Really? > Yes > So when the President/CEO of XYZ Corporation, who does business with a > customer whose domain happens to be managed by you, accidentally typos > an email address, you consider that a 'seriously fraudulent or otherwise > inappropriate' email? > Yes. Just like a misaddressed letter at the post office. It will not necessarily be returned. > You must not have any real commercial customers, because I would imagine > you would be a prime target for lawsuits for losing emails like this, as > it would only be a matter of time before it was something important sent > by someone important to someone else important. > I have enough, and there are no valid emails lost. > That said, I do have an email template I send to our users regularly > explaining why/how email should never be considered 100% reliable, and > if they ever send an email that has money riding on it being received, > they should follow it up with a phone call to make sure it actually was > received. I guess people like you are one of the reasons I have that > template and need to send it out on occasion. > > Ah, so even you admit email is not reliable. If it were, why would you encourage your people to follow up with a phone call? After all, if they didn't get a reject message, the email MUST have gone through. Jerry -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/543d3ea2.4070...@attglobal.net
Re: Recipient validation - WAS: Re: Moderated posts?
On Tue, Oct 14, 2014 at 10:48:38AM -0400, Tanstaafl wrote: > Rejecting will actually *reduce* traffic, because it doesn't accept the > entire messages, it slams the door at the RCPT-TO stage. Rejection can happen after the DATA phase as well. It's better if spam can be identified and rejected before this phase, for the reasons you have identified; but it isn't always possible. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141014145246.gb31...@chew.redmars.org
Re: Recipient validation - WAS: Re: Moderated posts?
On 10/14/2014 10:15 AM, Chris Bannister wrote: > On Tue, Oct 14, 2014 at 08:05:00AM -0400, Tanstaafl wrote: >>> To bounce all of those invalid addresses not only would further >>> increase the amount of junk on the internet, >> That is pure and absolute nonsense. The vast majority of spam comes from >> botnets, and *rejecting* garbage from these results in ZERO additional >> smtp traffic. > Are you confusing drop and reject? Doesn't a reject send a response > back, ie traffic, whereas a drop doesn't? No. An SMTP REJECT does not 'send' any additional traffic. It simply closes the connection with the appropriate 'response code', generally a 55# code. It then falls to the sending server to inform the sender of the 'failure to communicate' - which, if the sender is a botnet, won't happen. Rejecting will actually *reduce* traffic, because it doesn't accept the entire messages, it slams the door at the RCPT-TO stage. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/543d37c5.2070...@libertytrek.org
Re: Recipient validation - WAS: Re: Moderated posts?
On Tue, Oct 14, 2014 at 08:05:00AM -0400, Tanstaafl wrote: > > To bounce all of those invalid addresses not only would further > > increase the amount of junk on the internet, > > That is pure and absolute nonsense. The vast majority of spam comes from > botnets, and *rejecting* garbage from these results in ZERO additional > smtp traffic. Are you confusing drop and reject? Doesn't a reject send a response back, ie traffic, whereas a drop doesn't? Or are you meaning something else? -- "If you're not careful, the newspapers will have you hating the people who are being oppressed, and loving the people who are doing the oppressing." --- Malcolm X -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141014141530.GF27081@tal
Recipient validation - WAS: Re: Moderated posts?
On 10/13/2014 9:53 PM, Jerry Stuckle wrote: > Not a grey area at all. "...dropping mail > without notification of the > sender is permitted...". As for the "...long tradition and community > expectations..." - that's nice, but according to some estimates, > spammers now account for over 90% of the email traffic on the internet. And there are very simple ways to eliminate 90+% of that very simply (postfix+postscreen, without any additional tools), without risk of rejecting *any* legitimate email, and without *breaking SMTP*, which is what you are advocating. By adding a few simple additional tools (amavisd-new+spamassassin), you can easily deal with the remaining 9.9%... If you think I'm kidding, please by all means go make these silly statements on the postfix list and I'll just sit and watch the fun. > To bounce all of those invalid addresses not only would further > increase the amount of junk on the internet, That is pure and absolute nonsense. The vast majority of spam comes from botnets, and *rejecting* garbage from these results in ZERO additional smtp traffic. > but by not replying, servers tell the spammers what are valid email > addresses. More nonsense. Security through obscurity *never* works, and only, in this case totally breaks SMTP. > Finally, as for "...undermine confidence in the reliability of the > Internet's mail systems..." - it hasn't been reliable since spammers > virtually took over the email. And even when emails were rejected, it > still was no indication the recipient got the message. Of course it wasn't, but it was certainly a positive indication that the recipient did *not* receive it (as long as the sending server is properly configured). > There is, and never has been a reliable end-to-end verification of email > messages. Well, that at least is true. > BTW - by definition, any messages to any of the domains I manage without > a valid email address are "seriously fraudulent or otherwise inappropriate". Really? So when the President/CEO of XYZ Corporation, who does business with a customer whose domain happens to be managed by you, accidentally typos an email address, you consider that a 'seriously fraudulent or otherwise inappropriate' email? You must not have any real commercial customers, because I would imagine you would be a prime target for lawsuits for losing emails like this, as it would only be a matter of time before it was something important sent by someone important to someone else important. That said, I do have an email template I send to our users regularly explaining why/how email should never be considered 100% reliable, and if they ever send an email that has money riding on it being received, they should follow it up with a phone call to make sure it actually was received. I guess people like you are one of the reasons I have that template and need to send it out on occasion. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/543d116c.6020...@libertytrek.org
