Re: OT: Re: Recipient validation - WAS: Re: Moderated posts?
On 10/15/2014 3:13 PM, Miles Fidelman mfidel...@meetinghouse.net 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. snip 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: OT: Re: Recipient validation - WAS: Re: Moderated posts?
On 10/15/2014 4:58 PM, Joe j...@jretrading.com 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: 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: 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: OT: Re: Recipient validation - WAS: Re: Moderated posts?
On 10/16/2014 7:31 AM, Chris Bannister cbannis...@slingshot.co.nz 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 10/14/2014 1:58 PM, Miles Fidelman mfidel...@meetinghouse.net 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: OT: Re: Recipient validation - WAS: Re: Moderated posts?
Tanstaafl wrote:
On 10/14/2014 1:58 PM, Miles Fidelman mfidel...@meetinghouse.net 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: OT: Re: Recipient validation - WAS: Re: Moderated posts?
On Wed, Oct 15, 2014 at 9:01 PM, Miles Fidelman
mfidel...@meetinghouse.net wrote:
Tanstaafl wrote:
On 10/14/2014 1:58 PM, Miles Fidelman mfidel...@meetinghouse.net 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: OT: Re: Recipient validation - WAS: Re: Moderated posts?
Joel Rees wrote:
On Wed, Oct 15, 2014 at 9:01 PM, Miles Fidelman
mfidel...@meetinghouse.net wrote:
Tanstaafl wrote:
On 10/14/2014 1:58 PM, Miles Fidelman mfidel...@meetinghouse.net 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 RD
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: OT: Re: Recipient validation - WAS: Re: Moderated posts?
On 10/15/2014 12:50 PM, Miles Fidelman mfidel...@meetinghouse.net 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?
Tanstaafl wrote: On 10/15/2014 12:50 PM, Miles Fidelman mfidel...@meetinghouse.net 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: OT: Re: Recipient validation - WAS: Re: Moderated posts?
On Wed, 15 Oct 2014 15:13:27 -0400 Miles Fidelman mfidel...@meetinghouse.net 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
