Il 20/05/2014 17:23, Dan McAllister ha scritto:
Antonio,
While I understand your point, I think you have some misunderstandings
about how the "real" mail (snail-mail) works.
- If my address is 1234 Main St N, Anytown USA 12345 and you mail a
letter to 123 Main St, Sometown USA 12346 -- that letter will likely
*never *make it to *me *(You don't even have to bungle it in 3 places
like I did -- any SINGLE of those errors not just MAY, but PROBABLY
WILL, result in the failure of the INTENDED recipient getting the
letter. The days of your local postal carrier looking closely and
attempting (sometimes with great effort) to make the delivery to the
RIGHT PERSON are long (in some areas LONG LONG) since gone! If the
address is wrong, it'll be delivered to a nearby address (most likely
wrong), where it'll most likely be trashed. Want to test this? Send a
letter addressed to Daniel G McAllister, Saint Petersburg, FL 33712...
and see if you get anything back. (You won't -- and I won't get the
letter, either!)
This may be in your case, but here in Italy, usually paper mails with
wrong address are returned to sender.
Of course, it is different if cards come from abroad, as returning them
back has added costs.
But that does not change the quality of service, which can be improved
for free in electronic emails, returning the correct information to the
sender (reject with reason explained).
/ - Sad but funny aside: a neighbor of mine got into trouble at
the US post office by self-reporting that she received mail
addressed to me, but improperly delivered to her. She was
threatened with a fine and/or jail time because she gave me the
mail instead of returning it to the post office for re-delivery./
- JUST like the mail service, there is no guarantee that an e-mail
has been delivered UNLESS you ask for delivery confirmation.
Default is delivered for both. But with electronic email it's more easy
to report any failure.
- UNLIKE the mail service, you can choose NOT to verify delivery in
e-mail
The default is email delivered. The real difference is not on delivery,
but on reading receipt.
- UNLIKE the mail service, email has ZERO security during the
transmission of your message. (essentially, the "envelope" is NOT sealed!)
Paper postcards are readable by anyone. With TLS you may have ends
protected. In future we'll have TLS also on server to server
commmunication probably.
- LIKE the mail, email only promises a "best effort" to deliver the
message -- and like mail, the definition of "best effort" has changed
over the years.
Yes, it should improve a lot with email, so best effort should be better
than in the past.
But you also mentioned RFCs, and believe me I am a believer in
RFCs...however:
- While SOME RFCs state that there should be REJECT messages sent,
there are others that state that dropping undeliverable messages is
equally valid (e.g.: RFC 5321, ca. 2008) which noted the increased
implementation of NOT bouncing undeliverable messages for multiple
reasons. While the RFC cautioned against being too aggressive in
dropping messages, I think that reference was more to the act of
dropping SPAM and other "legitimately addressed" mail, based on
content. (And that is a DIFFERENT discussion)
NOTE: The RFCs also state that you should NOT accept RELAY mail on
port 25 (that is, outbound messages from users) [RFC 6409]. Unless
you're careful (and I am), QMAIL (and more specifically, QMT) violates
that RFC. Anyone know an ISP that blocks port 25 (Verizon
residential)? How about one that accepts mail on port 8080? (That's
supposed to be for non-root web servers) -- all "violations" of RFCs.
But since RFCs are there for "easy interoperability", so long as all
of your own clients know that you use port 8080 for SUBMISSION, you're
perfectly OK.... you just have to handle it when a client comes to you
and says "my mail program won't do that".
We relay on port 25 of a dedicated address with forced authentication
(it's a different server only for SMTP, not for MX), and also accept
relay on authenticated submission port 587.
So our authenticate customers can send anyway, because SMTP is different
from MX. Our port 25 on MX do not relay.
This change semplify life to our customers and does not affect in any
way external communications.
- RFCs are "standards" that are in place to make it easier for people
to send/receive data on the Internet without having to separately
negotiate and design the interfaces. They are not "laws" and not even
"rules"... they are more "guidelines"... what happens when you VIOLATE
RFCs is simply that you risk not being able to be easily accessed by
others... and in many cases (like the ESPs that use port 8080),
sometimes those "violations" are on purpose (to hide from abusers).
Another RFC that is broken OFTEN is the message coding for REJECT
messages -- 4.x.x messages are supposed to be for "delayed" delivery,
and 5.x.x messages for solid rejects. Also, the x and x values are
supposed to tell you the detailed REASON for the reject. Far too many
ESPs use "generic" failure reject messages, or will reject a message
with a 4.x.x result, or delay a message with a 5.x.x result... all in
error.
Someone which doe not respect the guidelines is going to give problems
to others. That does not means guidelines cannot be changed, but there
should be a managed process for that. Guidelines may evolve in time.
I know quite well all what you say before, and that does not change my
opinion about the added quality of service of electronic emails compared
to paper mails.
People must use emails in the most simple way, and our job is to
semplify their life.
Something can be complicated for us, but the goal is not semplify our
job, the goal is to give a better service.
FINALLY: I'm not against users(senders) getting information back, but
I'm also not about to _/facilitate /_/_abusers_ /in deceiving my
clients/users either. The BOUNCE mechanism isn't solely about address
phishing -- it is also abused by SPAMMERS who forge reply-to addresses
so that the "payload" SPAM is delivered as a BOUNCE message from a
legitimate server, even though the original source is illegitimate.
I adhere to some basic principles:
- properly addressed messages are ALWAYS delivered (even if SA gives
it a 100 score!).
- the only exceptions are when the sender's domain provides a
mechanism to validate the source & tells me to reject messages that
don't meet that validation. (This is what SPF, DomainKeys, DKIM, etc.
all try to do).
In that vein, I provide properly formatted and detailed REJECT
messages (so that a user might know why I rejected him as a sender),
but I do NOT provide BOUNCE messages.
The difference?
- a REJECT is a reply back to the original *sender's server*. I can
be reasonably certain I'm talking to the real server, as we're
expecting to trade TCP messages back and forth
- a bounce is a new message sent back to the person purporting to be
the sender. I have NO FAITH in the sender's self-reported address, so
I refuse to use it in ANY automated fashion - including, and
especially, bounce messages.
REJECT is the reasonable way to stop unwanted emails. Bounces are a
terrible solutions, but at the time Berstein wrote qmail there were no
SPAM problems (but I feel he wanted to ignore this problem, because this
could be a complication to his security model).
Again, all that is very clear, but I see a key point missing: who is the
owner od emails? Me or my customers?
Before I take a decision about implementing a filtering /rejecting rule,
I always ask if it is a necessary action, or if I'm going to damage the
right to receive emails.
I have the feeling you make the same, so I don't see problems.
===
These are just my thoughts -- but after being an ESP (Email Service
Provider) for more than 15 years now, I'm pretty strong in my
opinions! Not that they haven't changed... they have! I used to have a
single catchall account for ALL of my domains, and I used to have a
paid staffer whose job was to cull through those emails to see if any
could be forwarded to their legitimate recipients. What a naive little
nave I was back then! :^)
I don't represent that "I'm right & you're wrong" -- I am only
describing what I do, and attempting to explain why... I'm a firm
believer in the free market (of ideas AND of money), and firmly
believe that the Internet would have FAILED if people hadn't bent,
poked, prodded, and occasionally broken things over the years in the
name of improvements!
I agree generally with all you say, except one point: I don't believe in
freedom to use personal standards, as I've seen on net.
I believe in beeing tolerant with others, and being respectful of
standards in my job.
For example: qmail rejects emails if they do not respect CR\LF, I put a
patch to accept always messages despite of CR\LF, but my outgoing
messages respect the standard.
I've seen ISP blocking email from Italy or from Russia or from China,
just as their decision, and they were generating big problems only for
semplifying their job. I think you do not agree with that behaviour.
Regards,
Tonino
Dan McAllister
IT4SOHO
Anyone else remember ROT13 as a way to "encode" NSFW content?
Abj vf gur orfg gvzr! :)
On 5/19/2014 5:05 PM, Tonix - Antonio Nati wrote:
Strange, I have an opposite opinion on the most of catch-all and
delete usage I'm reading here in this thread.
Personally, and as provider of email business, I consider catch-all
account useful only when you have a new domain, and customer does not
know which mailboxes were running. So you set up a catchall account
and start creating all necessary accounts, and stop catch-all when
the most of accounts are created.
About deleting all email for not existing users, I consider it a bad
service to customers, as they have legitimate raports with business
partners, and if someone writes to the wrong address it is correct
and ethical to report them back that address is wrong, so they can
use another way to contact the recipient, instead of waiting for
never coming reply messages.
More, the abuse of deletion and missing respect for RFC forces users
to ask always for delivery and read receipt, incrementing the volume
of useless emails.
About signing headers with authenticating sender address, is a must
because it makes senders responsable for what they are sending, and
the most of our business customers wants their domain to be used only
for legitimate emails,
Of course other opinions may be based on different needs, but I think
respect of RFC should always be at first place, otherwise people will
look soon for other stable and reliable message delivery methods.
Something I think often about: as email providers, we should look
like real postmen: we cannot read (intentionally I mean), lose,
damage others emails. Virus and SPAM must be fought, and apart real
viruses and real spam all the remaining MUST be delivered. Any not
valid damage or loss could be legally pursued.
Regards,
Tonino
Il 19/05/2014 21:10, Eric Shubert ha scritto:
On 05/19/2014 08:06 AM, Jim Shupert wrote:
How might one do - have a DELETE rule for badly addressed messages. I
just drop them and forget about it?
is it as easy as: " Set catchall email deleted " from admin
in truth ... i thought you HAD to have a catch all account -- yes - i
would rather not.
thanks
Personally, I use a catchall account for my domain, and I don't get
very much spam there at all. I do a few use a few tools for
mitigating this.
1) the badmailto file can specify addresses with a regex. So for
example, if your domain accounts don't contain numbers or whatever
special characters, or your accounts always follow a certain
pattern, you can write badmailto rules to reject these attempts. I
used to get a lot of spam with numbers in the account name, and
eliminated them witha few badmailto rules. This file can also be
used to reject messages to defunct accounts.
2) use spamdyke to blacklist local domains. This seems counter
intuitive, but so long as legit users always authenticate and only
send email via your server, this works nicely.
That being said, I can see where some domains would want to simply
delete these messages. While deleting messages goes against the
RFCs, doing so certainly appears to be a best practice. Some rules,
while well intended, have unintended consequences. I think this is
one such rule.
also that strategy of : " giving each user a separate mailbox name and
e-mail address "
yes , that is interesting -- I can see how that would work
....unfortunately in my current situation folks already have the
"configuration " that we have.
but maybe for a new bunch of folks a new domain
This is a most excellent method of managing user accounts. I've
considered doing this, but haven't actually implemented it yet.
Along these lines, I've also considered modifying the header record
qmail adds so that the authentication account isn't listed in its
entirety. This would help to protect the actual account name.
thanks for the food for thought ,,, a hardy meal.
jim
Thanks as well.
--
IT4SOHO, LLC
33 - 4th Street N, Suite 211
St. Petersburg, FL 33701-3806
CALL TOLL FREE:
877-IT4SOHO
877-484-7646 Phone
727-647-7646 Local
727-490-4394 Fax
We have support plans for QMail!
--
------------------------------------------------------------
Inter@zioni Interazioni di Antonio Nati
http://www.interazioni.it [email protected]
------------------------------------------------------------
